I have already done some researches online, and the best solution seems to use a better algorithm to generate new key pairs. But right now I still need to use ssh-dss key pairs for internal automation.
(I know that since openssh 7.0, ssh-dss is disabled by default, we need to explicitly add
PubkeyAcceptedKeyTypes +ssh-dssto ssh configuration to re-enable it.)
Environmet:
OpenSSH_8.0p1, OpenSSL 1.1.1c FIPS 28 May 2019
Linux hostname 5.1.19-300.fc30.x86_64 #1 SMP Mon Jul 22 16:32:45 UTC 2019 x86_64 x86_64 x86_64 GNU/LinuxHere is the checklist for what I have done so far:
- Create a user with password (some posts said that it might need a password)
- Create
.sshfolder, set the public key in.ssh/authorized_keys, make sure that they have 700, 600 permission and right owner rather than root. - Check
/etc/ssh/sshd_config, make sure that we havePubkeyAuthentication yes(usually it's default value) - Explicitly enable
ssh-dss- Add
PubkeyAcceptedKeyTypes +ssh-dssin/etc/ssh/sshd_configon server - Add
PubkeyAcceptedKeyTypes +ssh-dssin~/.ssh/configon both server and client sides
- Add
- Restart sshd service to pick the new change
However, I was still asked for password.
- Check
/var/log/secure, I see:
userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes
- Check
ssh -Q key:
ssh-ed25519
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521Looks like that the ssh-dss should be in the list already, why I still see that error when ssh with private key file?
I did not got much more information from /var/log/secure after I set ssh log level to VERBOSE:
Jul 28 18:40:44 re-pkg-fedora30 sshd[1374]: Connection from 10.32.34.60 port 63863 on 10.140.143.132 port 22
Jul 28 18:40:44 re-pkg-fedora30 sshd[1374]: Failed publickey for mambop from 10.32.34.60 port 63863 ssh2: RSA SHA256:7EgHyu1SFM76cXlMGxHcvqg/C2xqbfbrQCfX5WCnOgc
Jul 28 18:40:44 re-pkg-fedora30 sshd[1374]: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes [preauth]
Jul 28 18:40:45 re-pkg-fedora30 sshd[1374]: Connection closed by authenticating user mambop 10.32.34.60 port 63863 [preauth] 9 2 Answers
I had the same problem with RHEL 8.0, and initially went the same route, adding PubkeyAcceptedKeyTypes=+ssh-dss to /etc/ssh/sshd_config, but it still didn't work. Then I realized that /etc/ssh/ssh_host_dsa_key didn't exist, so I created that, but still no success.
Then I found documentation about the RHEL 8 system-wide cryptographic policies, which right at the beginning explains that a LEGACY policy level allows the DSA algorithm. And indeed, all that is required to make SSH pubkey authentication with a DSA key work (even without a restart of sshd) is
$ update-crypto-policies --set LEGACYNote that this also weaken several other security aspects. I didn't care, because it's a short-lived test system, anyway.
1I recently went to Fedora 31 from 28 and had the same issue. Not sure why, but I had exactly the same issues. It told me that the key algorithm was there after doing the -Q key. At one point it looked like I had got over that error but was then getting no key exchange algorithm and didn't know what I needed for DSA.
In the end I decided to upgrade to ECDSA with 512 bits and it appears to work for me. I know that isn't going to help you because you probably have thousands of users all using the old certs, but wanted to let you know you were not alone with this issue.
Even though the OpenSSH documentation says you can downgrade, I am now wondering if that is really the case with OpenSSH version 8. Version 7 was definitely supporting it because that was what I was doing after the last upgrade and before this upgrade to version 31.