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
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)
firstname.lastname@example.org: Permission denied (publickey,gssapi-keyex,gssapi-with-mic)
Bash command prompt on server
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.
The Fedora 33 removes SHA1, which will certainly be in the release notes . 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
I will keep the bug open until we will make sure the release notes are fixed.
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`:
While less than desirable, it works.
Overall, this can likely be marked as a duplicate of bug 1881301.
(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.
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.
(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.