Server still prompts for password after SSH configuration, Ubuntu 17.10 x64

by user242007   Last Updated January 12, 2018 22:00 PM

EDIT: After consulting verbose logs as was suggested, I found the error myself. Answer is at the bottom.

I have a DigitalOcean droplet I want to use as a development environment. I've created a non-root user with sudo privileges to do all the actual work, and have set this user up with the public key in my pair via ssh-copy-id. Attempting to copy the key over again confirms that the key is present and recognized:

/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.

This is after trying the following suggestions:

  • Empty the contents of .ssh on both machines, generate and copy a new key
  • Use chmod to ensure that .ssh is set to 700 and authorized_keys is set to 600 on the VPS.
  • Uncommented the line in etc/ssh/sshd_config stating PubkeyAuthentication yes as well as AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2 followed by restarting the ssh daemon on the VPS.
  • Rebuilding the droplet and trying again from scratch
  • Manually copying over the key using cat
  • Trying to setup the key with the root user to then swap over to the non-root user.

At this stage, any attempt to connect via SSH still prompts for the user's password even though I explicitly set the key to be passwordless, and failing to provide this password results in this error: Permission denied (publickey,password). If I provide the password, I'm still able to log in directly as the user.

The following are the verbose logs before the password prompt appears:

OpenSSH_7.2p2 Ubuntu-4ubuntu2.2, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolving "138.197.31.224" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 138.197.31.224 [138.197.31.224] 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: key_load_public: No such file or directory
debug1: identity file /home/user/.ssh/id_dsa type -1
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.2p2 Ubuntu-4ubuntu2.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5p1 Ubuntu-10
debug1: match: OpenSSH_7.5p1 Ubuntu-10 pat OpenSSH* compat 0x04000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 138.197.31.224:22 as 'user'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: [email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected],zlib
debug2: compression stoc: none,[email protected],zlib
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,[email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
debug2: host key algorithms: ssh-rsa,rsa-sha2-512,rsa-sha2-256,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],aes[email protected]
debug2: ciphers stoc: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected]
debug2: MACs ctos: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: [email protected],[email protected],[email protected],[email protected],[email protected],[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,[email protected]
debug2: compression stoc: none,[email protected]
debug2: languages ctos:
debug2: languages stoc:
debug2: first_kex_follows 0
debug2: reserved 0
debug1: kex: algorithm: [email protected]
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:cAw/cF/p37TL25mwRKivxJpMCPyrCMFo5YaeTYQ2Wvo
debug1: Host '138.197.31.224' is known and matches the ECDSA host key.
debug1: Found key in /home/user/.ssh/known_hosts:1
debug2: set_newkeys: mode 1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug2: key: /home/user/.ssh/id_rsa ((nil))
debug2: key: /home/user/.ssh/id_dsa ((nil))
debug2: key: /home/user/.ssh/id_ecdsa ((nil))
debug2: key: /home/user/.ssh/id_ed25519 ((nil))
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug2: service_accept: ssh-userauth
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: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

If we look at the above logs, these are the most relevant lines:

debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

We can see that ssh has four default files it will check for, which is fine assuming you let ssh-keygen provide a default name during generation. However, if you give your key a special name, you will have to point ssh to the location of the private key, as it does not know to look for it. After I noticed this, I attempted to log in with the following command:

ssh [email protected] -i .ssh/custom_named_rsa

. . . and was successful. Note that the above just happens to be the relative path to the key from the directory I was in, the usual considerations of pathing apply. Thanks to both suggestions to process logs, especially the one for verbose logging on the client side.

Tags : ubuntu ssh rsa


Answers 2


You need to look in the logs on the server to find out why it is rejecting the key. it is normally evident from the log messages what the problem is.

user449299
user449299
January 12, 2018 21:10 PM

To ensure this can be properly closed now that I've figured it out, I will reiterate here in a self-answer what I said above:

Attempt to connect to the remote server using ssh -vv [email protected]. This will show the verbose logs of the attempt, which at the very bottom just before the password prompt yields the following important lines:

debug1: Next authentication method: publickey
debug1: Trying private key: /home/user/.ssh/id_rsa
debug1: Trying private key: /home/user/.ssh/id_dsa
debug1: Trying private key: /home/user/.ssh/id_ecdsa
debug1: Trying private key: /home/user/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: password

We can see that ssh has four default files it will check for, which is fine assuming you let ssh-keygen provide a default name during generation. However, if you give your key a special name, you will have to point ssh to the location of the private key, as it does not know to look for it. After I noticed this, I attempted to log in with the following command:

ssh [email protected] -i .ssh/custom_named_rsa

. . . and was successful. Note that the above just happens to be the relative path to the key from the directory I was in, the usual considerations of pathing apply.

user242007
user242007
January 12, 2018 21:40 PM

Related Questions


Unbuntu KVM Bridged DHCP nothing works

Updated March 26, 2018 04:00 AM

Linux config synchronization using cloud

Updated June 19, 2018 09:00 AM


Blocking Azure/Google Cloud IP ranges

Updated December 13, 2015 14:00 PM