SSH DSA keys no longer work for password-less authentication

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?

D.W.

Posted 2015-12-23T01:17:42.900

Reputation: 1 269

Dupe of http://superuser.com/questions/962918/pubkeyacceptedkeytypes-and-ssh-dsa-key-type and (cross) http://unix.stackexchange.com/questions/247612/ssh-keeps-skipping-my-pubkey-and-asking-for-a-password

– dave_thompson_085 – 2015-12-23T04:32:46.563

Thanks, @dave_thompson_085. This is not a dupe of http://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 http://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. – 2015-12-23T06:24:06.953

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 – 2015-12-27T01:08:08.543

Answers

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.

D.W.

Posted 2015-12-23T01:17:42.900

Reputation: 1 269

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 – 2015-12-23T11:59:48.097

@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. – 2015-12-23T17:09:30.407

See here for a more detailed discussion.

– D.W. – 2015-12-23T17:09:33.533

My two cents

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

Create a new key, by using recent tool.

Then copy the new public key (into the clipbord)
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
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

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 ;-)

You could even re-check if everything is ok:
```
ssh user@host uptime
```

F. Hauri

Posted 2015-12-23T01:17:42.900

Reputation: 1 394

It's not obvious to me why you think that editing ~/.ssh/config not such a good idea. – D.W. – 2018-10-19T15:38:39.787

Because this is deprecated and ssh author recommand to not use. See http://www.openssh.com/legacy.html

– F. Hauri – 2018-10-19T19:37:29.993

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. – 2018-10-19T21:16:34.183

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 – 2018-10-21T11:51:44.437