2

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-dss to 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/Linux

Here 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 .ssh folder, 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-dss in /etc/ssh/sshd_config on server
    • Add PubkeyAcceptedKeyTypes +ssh-dss in ~/.ssh/config on both server and client sides
  • 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
[email protected]
ssh-rsa
ssh-dss
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]

Looks 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]
Improve this question
9
  • Does your /etc/ssh/sshd_config file have the lines PasswordAuthentication no and ChallengeResponseAuthentication no in it? Cause if so you shouldn't get a password prompt whether the pubkey auth fails or not. Also, have you made sure the client side config (/etc/ssh/ssh_config or ~/.ssh/config) have also had the necessary keytypes enabled?
    – Cliff Armstrong
    Commented Jul 26, 2019 at 23:08
  • Never mind, i missed it when I read the question the first time. You clearly do. You should probably check the server sshd, auth, and pam logs to see if you can spot what sshd's reasoning for giving you a password prompt is.
    – Cliff Armstrong
    Commented Jul 26, 2019 at 23:09
  • @CliffArmstrong Thanks for your quick response! Yes I got the reason by not know why: userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes
    – Zhipeng Yang
    Commented Jul 26, 2019 at 23:25
  • Apparently, on the client side you need to enable ssh-dss in the host key algorithms, not just accepted pubkeys. Try adding HostKeyAlgorithms +ssh-dss to your ~/.ssh/config file.
    – Cliff Armstrong
    Commented Jul 26, 2019 at 23:33
  • Interestingly, when I do ssh -Q key my openssh installations all list ssh-dss as a supported key algorithm despite it being rather thoroughly and explicitly disabled in my configs (my openssh servers and clients are heavily hardened). So apparently that command's output isn't reliable for showing current configuration.
    – Cliff Armstrong
    Commented Jul 26, 2019 at 23:36

2 Answers 2

Reset to default
6

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 LEGACY

Note that this also weaken several other security aspects. I didn't care, because it's a short-lived test system, anyway.

Improve this answer
1
  • 1
    Thanks, update policies command works perfectly. It should be accepted answer.
    – Sylwester Zarębski
    Commented Jun 29, 2020 at 16:36
0

I 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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .