67

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 [email protected] <implicit> none [preauth]
debug1: kex: server->client [email protected] <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 [email protected] <implicit> none
debug1: kex: client->server [email protected] <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:
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

111

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.

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

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!

1
  • 1
    "I tried Jakuje's Answer No luck" The above is Jakuje's answer. It'e exactly the same. 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

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

You must log in to answer this question.

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