66

Every time I ssh onto my remote server, I need to provide the password. I copied my public key (id_dsa.pub) to the remote server using:

ssh-copy-id -i id_dsa.pub user@server

I checked it was correctly added to authorized_keys. All the file/directory permissions are correct:

~user 755
~user/.ssh 700
~user/.ssh/authorized_keys 640
~user/.ssh/id_dsa.pub 644

The PasswordAuthentication field in /etc/ssh/sshd_config is set to yes. I put the sshd in debug mode and added the verbose switch to the ssh command. I get the impression that the server did not try to use id_pub.dsa because of the line 

Skipping ssh-dss key: ........... not in PubkeyAcceptedKeyTypes

There is no encrypted disc on server side. Any ideas how to progress? Here is the ssh daemon debug info:

sudo /usr/sbin/sshd -d
====
debug1: sshd version OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: private host key: #0 type 1 RSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type DSA
debug1: private host key: #1 type 2 DSA
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type ECDSA
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv[0]='/usr/sbin/sshd'
debug1: rexec_argv[1]='-d'
Set /proc/self/oom_score_adj from 0 to -1000
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
debug1: Server will not fork when running in debugging mode.
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from xxx port 63521 on yyy port 22
debug1: Client protocol version 2.0; client software version OpenSSH_7.1
debug1: match: OpenSSH_7.1 pat OpenSSH* compat 0x04000000
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: permanently_set_uid: 115/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none [preauth]
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none [preauth]
debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user damian service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: PAM: initializing for "damian"
debug1: PAM: setting PAM_RHOST to "freebox-server.local"
debug1: PAM: setting PAM_TTY to "ssh"
Connection closed by xxxx [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed
debug1: do_cleanup

Here is the ssh verbose output:

$ ssh -v user@server
OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015
debug1: Connecting to server [xxxx] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_rsa-cert type -1
debug1: identity file /home/user/.ssh/id_dsa type 2
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: match: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3 pat OpenSSH_6.6.1* compat 0x04000000
debug1: Authenticating to server:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:v4BNHM0Q33Uh6U4VHenA9iJ0wEyi8h0rFVetbcXBKqA
debug1: Host 'server' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:2
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Skipping ssh-dss key /home/user/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug1: Next authentication method: password
user@server's password:
Improve this question
2
  • 1
    See also superuser.com/q/1016989/93541 for the same problem (and essentially the same solution).
    – D.W.
    Dec 23, 2015 at 6:24
  • Note that if the sshd_config on the destination has PubkeyAuthentication no, you will always be prompted for a password. Set it to yes and restart the sshd (on the destination host) to enable pubkey authentication.
    – C. Kelly
    Apr 25, 2019 at 13:39

5 Answers 5

Reset to default
109

The new openssh version (7.0+) deprecated DSA keys and is not using DSA keys by default (not on server or client). The keys are not preferred to be used anymore, so if you can, I would recommend to use RSA keys where possible.

If you really need to use DSA keys, you need to explicitly allow them in your client config using

PubkeyAcceptedKeyTypes +ssh-dss

Should be enough to put that line in ~/.ssh/config, as the verbose message is trying to tell you.

Improve this answer
5
  • 8
    +1, but better advice would be to use another, non-deprecated, key type...
    – jasonwryan
    Dec 5, 2015 at 21:15
  • @jasonwryan Thanks for comment. Certainly. I will update the answer.
    – Jakuje
    Dec 5, 2015 at 21:17
  • Thanks Jakuje! That makes sense, I didn't realise dsa was oldhat. I generated a new key pair ssh-keygen rsa is the default now. I will try to login with this from the other machine tomorrow.
    – Damo
    Dec 8, 2015 at 23:12
  • If you're ~/.ssh/config doesn't exist just create it. And remember to set the corect permissions: chmod 600 ~/.ssh/config.
    – Florian Brucker
    Dec 2, 2016 at 8:31
  • @knb don't do that. It will avoid using any other algorithms in future, since you removed all the elliptic curve algorithms.
    – Jakuje
    Aug 3, 2017 at 10:16
1

In my case, I was having this issue because another user had changed the AuthorizedKeysFile location. Since there was no authorized_keys for other users in this location, login would default to password, even though authorized_keys existed with correct permissions in the default home directory.

AuthorizedKeysFile   /etc/ssh/%u/authorized_keys

Commented this modified line out and restarted sshd service to go back to default setting, which then allowed other users to authenticate using their keys.

Improve this answer
2
  • I just resolved a similar issue on a RHEL7 system where the SELinux context was not properly initialized on the user's homedir, so ssh wasn't able to read the authorized keys file despite the standard permissions. I ultimately ended up running restorecon -Rv /home to fix it for the other users who were also set up incorrectly on the same system.
    – dannysauer
    Jan 26, 2017 at 21:21
  • cool story, but not really related to the question.
    – Julian
    Jul 9, 2020 at 18:45
1

I tried Jakuje's Answer No luck. But i understand the problem from there. Tried to add comment but need reputation that why adding anwser.

But the configuration file for me /etc/ssh/ssh_config

  1. sudo nano /etc/ssh/ssh_config
  2. PubkeyAcceptedKeyTypes +ssh-dss Added this line at the bottom.
  3. Save and tried again.

Worked!

Improve this answer
1
  • 1
    "I tried Jakuje's Answer No luck" The above is Jakuje's answer. It'e exactly the same.
    – T.J. Crowder
    Sep 6, 2020 at 8:20
0

Just to summarize what I did in order to SSH to raspberry Pi.

In server machine (raspberry Pi): 

$ ip addr show

or simply ip a, this will display the IP address of the Pi machine - host_ip

$ mkdir .ssh

In client machine (ubuntu):

$ ssh-keygen -t rsa

Credit to @Jakuje above. I was initially using ssh-keygen -t dsa for the key generation, and ssh kept asking me for password. ssh -v ip-address doesn't give me much useful info, until I saw @Jakuje's answer

$ cat .ssh/id_rsa.pub | ssh user_id@host_ip 'cat >> ~/.ssh/authorized_keys'

replace user_id and host_ip, when prompt, provide the password for the Pi machine

$ ssh user@ip_address

successfully logged into PI, no more password

Improve this answer
-1

dsa didn't work for me. rsa did.

ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
cat /Users/user_name/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

And I can ssh without password.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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