SSH DSA keys no longer work for password-less authentication

44,162

This is a result of upgrading to OpenSSH 7.0. As the release notes for OpenSSH 7.0 say, "Support for ssh-dss host and user keys is disabled by default at run-time".

The solution is to add the following line to ~/.ssh/config on every client machine (every machine where you run the SSH client):

PubkeyAcceptedKeyTypes=+ssh-dss

If the server is using OpenSSH 7.0 or newer, you'll also need to add this line to /etc/ssh/sshd_config on each server machine.

Alternatively, you can generate an entirely new SSH key and add it to your authorized_keys file on every server you ever want to log into. I recommend you use RSA, to avoid compatibility woes. I don't recommend ECDSA, as apparently gnome-keyring-daemon doesn't automatically pick up SSH keys of type ECDSA.


Editorial remark: Why did the OpenSSH folks disable DSA keys? I don't know. As far as I'm able to ascertain, there's nothing wrong with the security of DSA keys (ssh-dss). The OpenSSH web page claims that ssh-dss is weak, but as far as I'm aware, 1024-bit ssh-dss is no weaker than 1024-bit RSA, and 1024-bit RSA keys are not disabled.

Share:
44,162

Related videos on Youtube

Jiaa Memon
Author by

Jiaa Memon

Updated on September 18, 2022

Comments

  • Jiaa Memon
    Jiaa Memon over 1 year

    After upgrading to Fedora 23, passwordless (public-key-based) authentication no longer works in SSH: when trying to SSH to some host, it prompts for my password at the remote host. I can't get it to use my SSH private key. Everything worked fine with Fedora 22.

    My public key is a DSA key (~/.ssh/id_dsa.pub). I'm using OpenSSH 7.1 (openssh-7.1p1-5.fc23.x86_64).

    How do I get password-less authentication to work correctly again?

  • Jakuje
    Jakuje over 8 years
    The key type selection is discussed on Security for some time. The security of DSA keys is questionable from the beginning and less secure if you don't have good random generator (which you can't make sure). And since now there are other possible key types to use, there is no reason to retain the questionable ones.
  • Jiaa Memon
    Jiaa Memon over 8 years
    @Jakuje, yes, key type selection is discussed on Information Security here and here. I read all of that before writing my editorial remark, and I remain puzzled why DSA keys were disabled: they are no weaker than RSA keys of the same length, which were not disabled. There's nothing in any of those threads that indicates DSA is "questionable", and as Thomas Pornin says, "there is no security-related reason to prefer one type over any other, assuming large enough keys". (cont.)
  • Jiaa Memon
    Jiaa Memon over 8 years
    See here for a more detailed discussion.
  • Jiaa Memon
    Jiaa Memon over 5 years
    It's not obvious to me why you think that editing ~/.ssh/config not such a good idea.
  • F. Hauri
    F. Hauri over 5 years
    Because this is deprecated and ssh author recommand to not use. See openssh.com/legacy.html
  • Jiaa Memon
    Jiaa Memon over 5 years
    Oh, I understand. It sounds like your concern is not with the idea of editing ~/.ssh/config per se but rather with the idea of allowing DSA. Thanks for explaining. That makes sense. (I think I've already addressed in my answer and my comments why I find that recommendation to be puzzling, but I won't try to debate that here.)
  • F. Hauri
    F. Hauri over 5 years
    Editing .config make you able to execute ssh for a long time and even fogive that you use weak algorithm. By using -o Pubkey... at command line, you won't forgive that there is something to upgrade.