Created attachment 1729637 [details] Output of various ssh related commands How reproducible: * always Steps to reproduce: * Upgrade from Fedora 32 to Fedora 33 * crypto-policies-20200918-1.git85dccc5.fc33.noarch * libssh-0.9.5-1.fc33.x86_64 * openssh-8.4p1-2.fc33.x86_64 * Open gnome-terminal * Load ssh key via "ssh-add ~/.ssh/id_rsa_phabprod" and entering your passphrase * ssh to corresponding server via command: ssh phab1001 Expected results: * Either a successful SSH connection as in Fedora 32, * or at least some info why things don't work and what to do (as I might not know about cryptop-policies changes; and if I know or find out I'd prefer to get back from LEGACY to DEFAULT policy) Actual results: * An unexpected "Password:" prompt on the terminal * Unable to connect (see attachment) * Be puzzled * Find out about https://fedoraproject.org/wiki/Releases/33/ChangeSet#Strong_crypto_settings:_phase_2 and bug 1821875 * Change from current "update-crypto-policies --set DEFAULT" to "update-crypto-policies --set LEGACY" * Reboot * Things work again and you can connect * Be still puzzled why - the key has 2048 bits and no SHA1 used (and AFAIK no TLS1.0 or TLS1.1, but no idea how to reliably check) * See that other users are also puzzled e.g. in bug 1885149 or bug 1884920 Further information: * See attachment for output of "ssh-keygen -l -f"; "more ~/.ssh/config"; "ssh -vvv" (via proxy); "ssh -vvv" (to proxy itself)
> debug1: Executing proxy command: exec ssh -a -W phab1001:22 aklapper.org You are using proxy host to connect to the final target. If the pubkey authentication to proxy fails, it falls back to the password authentication. The bastion is running openssh 7.4 on Debian: > debug1: match: OpenSSH_7.4p1 Debian-10+deb9u7 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002 It has a known bug that it does not report correct signature algorithms as discussed in #1881301. Please, report the issue to Debian developers. I will have a look if the workaround suggested in the referenced bug work. *** This bug has been marked as a duplicate of bug 1881301 ***