27

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?

Improve this question
3
  • 1
    Dupe of superuser.com/questions/962918/… and (cross) unix.stackexchange.com/questions/247612/…
    – dave_thompson_085
    Dec 23, 2015 at 4:32
  • 1
    Thanks, @dave_thompson_085. This is not a dupe of superuser.com/q/962918/93541. That question is asking how to use ssh -Q. This is asking how to trouble-shoot a failure of SSH. I did find some of the material at superuser.com/q/962918/93541 and elsewhere helpful in identifying this solution, but the answer there describes how to use ssh -Q and does not answer this question (e.g., it doesn't explain how to fix this problem), so in my view it's not a dup. The one on Unix & Linux is very similar; I wish I'd seen that one earlier. Thanks again for the links!
    – D.W.
    Dec 23, 2015 at 6:24
  • Ack, you're right. I had them both bookmarked as "OpenSSH 7.0 no DSA" which in the former case is not close enough. Sorry.
    – dave_thompson_085
    Dec 27, 2015 at 1:08

2 Answers 2

Reset to default
44

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.

Improve this answer
3
  • 2
    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.
    – Jakuje
    Dec 23, 2015 at 11:59
  • 2
    @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.)
    – D.W.
    Dec 23, 2015 at 17:09
  • See here for a more detailed discussion.
    – D.W.
    Dec 23, 2015 at 17:09
0

My two cents

As editing .ssh/config file in order to permit this seem to be a not so good idea, I suggest

  1. Create a new key, by using recent tool.

    Then copy the new public key (into the clipbord)

  2. Log one last time by using old key:

    ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host

    Then upgrade @host's authorized_keys file, by adding your new pubkey and logout

    cat >>.ssh/authorized_keys

    paste, then Ctrl+D

  3. Log with new key by using default syntax:

    ssh user@host

    1. Then upgrade @host's authorized_keys file, by removing you old pubkey (I use sed -e 1d -i .ssh/authorized_keys when my old pubkey is on line 1 of this file).

    2. I suggest to upgrade you ssh server if you can.

    3. logout

  4. Test if old key don't work anymore.

    ssh -i .ssh/id_dsa.pub -o PubkeyAcceptedKeyTypes=+ssh-dss user@host
...
Permission denied...

    This have to not work ;-)

  5. You could even re-check if everything is ok:

    ssh user@host uptime
Improve this answer
4
  • 1
    It's not obvious to me why you think that editing ~/.ssh/config not such a good idea.
    – D.W.
    Oct 19, 2018 at 15:38
  • Because this is deprecated and ssh author recommand to not use. See openssh.com/legacy.html
    – F. Hauri - Give Up GitHub
    Oct 19, 2018 at 19:37
  • 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.)
    – D.W.
    Oct 19, 2018 at 21:16
  • 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.
    – F. Hauri - Give Up GitHub
    Oct 21, 2018 at 11:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.