Bug 1897952

Summary: crypto-policies update in F33 causes SSH connection to fail without clear indication of reason
Product: [Fedora] Fedora Reporter: Andre Klapper <a9016009>
Component: crypto-policiesAssignee: Red Hat Crypto Team <crypto-team>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 33CC: crypto-team, jjelen, lef, n.mavrogiannopoulos, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-11-16 09:22:06 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Output of various ssh related commands none

Description Andre Klapper 2020-11-15 19:57:09 UTC 
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)
Comment 1 Jakub Jelen 2020-11-16 09:22:06 UTC 
> 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 ***