Bug 1884920

Summary:	Cannot ssh into CentOS 6 using ssh key authentication
Product:	[Fedora] Fedora	Reporter:	Scott Reese <sjreese>
Component:	openssh	Assignee:	Jakub Jelen <jjelen>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	low	Docs Contact:
Priority:	unspecified
Version:	33	CC:	bfinger, crypto-team, dgsiegel, dwalsh, jjelen, jpazdziora, kecarter, lkundrak, mattias.ellert, neteler, plautrba, tmraz, wijngaarde, work.eric, zawertun
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2020-10-29 15:45:32 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:

Description Scott Reese 2020-10-03 15:36:38 UTC

Description of problem:
If you have a CentOS 6 server set up to use ssh keys for authentication, you cannot log in using the openssh client in Fedora 33. If the CentOS 6 server is set to also allow password authentication, it will fall back to that and login will succeed. If the server does not allow any other authentication methods, authentication will fail and login will fail.

Version-Release number of selected component (if applicable):
Fedora 33 openssh-clients 8.4p1-1
CentOS 6.10 openssh-server-5.3p1-124

How reproducible:
Attempt to log using ssh keys (identity file). If server is configured to allow password authentication, the login will fall back and ask for the password. If server is not configured to allow password authentication (PasswordAuthentication no), then login will fail

Steps to Reproduce:
1. Load ssh key for server (ssh-add .ssh/id_rsa)
2. ssh to server (ssh server.name.here)
3.

Actual results:
scott.here: Permission denied (publickey,gssapi-keyex,gssapi-with-mic)

Expected results:
Bash command prompt on server

Additional info:
This isn't a bug so much as it is an incompatibility between the security protocols that CentOS 6.10 supports and the ones that Fedora 33 supports. If you run ssh -v server.name.here, it says that there are no compatible signature algorithms:

debug1: send_pubkey_test: no mutual signature algorithm

It may not be a problem because there is limited overlap between the release of Fedora 33 and the EOL of CentOS 6, but I think it might be worth an entry in the release notes. It would be easy for people to get locked out of their servers.

Comment 1 Jakub Jelen 2020-10-05 07:23:18 UTC

The Fedora 33 removes SHA1, which will certainly be in the release notes [1]. But it did not mention ssh at all yet, but we are going to fix it.

There is a simple workaround by using ECDSA authentication and host keys (which use SHA2 ever since) or creating a following configuration snippet to connect to legacy hosts:

  # legacy host not supporting RSA with SHA2
  Host server.name.here:
    PubkeyAcceptedKeyTypes ssh-rsa

I will keep the bug open until we will make sure the release notes are  fixed.

[1] https://fedoraproject.org/wiki/Releases/33/ChangeSet#Strong_crypto_settings:_phase_2

Comment 2 Kevin Carter 2020-10-26 18:34:14 UTC

Just to confirm, while running F33 I too had issues when interacting with legacy SSH servers. The noted config is a good work-around for anyone who's needing to interact with existing SSH servers; especially those working in or around an ssh based git workflow (the OpenStack (OpenInfrastructure) community, github, etc).

The following config was added to my user's ssh config `~/.ssh/config`:


  Host review.opendev.org
    PubkeyAcceptedKeyTypes ssh-rsa


While less than desirable, it works.

Comment 3 Jan Pazdziora (Red Hat) 2020-10-28 18:06:39 UTC

Overall, this can likely be marked as a duplicate of bug 1881301.

Comment 4 Jakub Jelen 2020-10-29 12:00:50 UTC

(In reply to Jan Pazdziora from comment #3)
> Overall, this can likely be marked as a duplicate of bug 1881301.

No, it is not the same. The bug #1881301 is a main issue in Debian, which has newer OpenSSH, but with a bug preventing negotiating the SHA2 methods even though they are properly implemented (the only openssh release that had this problem). The OpenSSH in RHEL6/CentOS6 does not support rsa-sha2 and never will. Not even the patch proposed in bug #1881301 is going to address the issue of connecting to the RHEL6/CentOS 6 servers.

The other possible workaround is to use ECDSA keys, which are available in RHEL6/CentOS6 and use SHA2 implicitly.

Comment 5 Tomas Mraz 2020-10-29 15:45:32 UTC

This is expected behavior. You have to switch to the LEGACY crypto policy to communicate with legacy systems. And RHEL-6/CentOS-6 is certainly a legacy system.

Comment 6 Jan Pazdziora (Red Hat) 2020-11-02 10:22:13 UTC

(In reply to Jakub Jelen from comment #4)
> (In reply to Jan Pazdziora from comment #3)
> > Overall, this can likely be marked as a duplicate of bug 1881301.
> 
> No, it is not the same.

Mea culpa. Thanks for the explanation.