Home / ubuntu / Questions / 394496
In Process
JohnMerlino
Asked: 2013-12-23 15:18:09 +0800 CST

ssh key authentication still prompts password

  • 772

I got ssh key authentication working on my production server quite swiftly. However, I have been struggling to get it to work on my development server.

First, I generated the keys (I use Ubuntu on both home and server):

$ ssh-keygen -t rsa -f ~/.ssh/production-key.id_rsa

.ssh$ ls -l
total 36
-rw-rw-r-- 1 viggy viggy  234 Dec 22 15:21 config
-rw------- 1 viggy viggy 1766 Dec 22 15:03 development-key.id_rsa
-rw-r--r-- 1 viggy viggy  397 Dec 22 15:03 development-key.id_rsa.pub
-rw------- 1 viggy viggy 1766 Dec 22 13:12 production-key.id_rsa
-rw-r--r-- 1 viggy viggy  397 Dec 22 13:12 production-key.id_rsa.pub
-rw------- 1 viggy viggy 1766 Sep  5 20:36 id_rsa
-rw-r--r-- 1 viggy viggy  403 Sep  5 20:36 id_rsa.pub
-rw-r--r-- 1 viggy viggy 4422 Dec 22 11:45 known_hosts

I added development private key to my config file:

vim config
Host production
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/production-key.id_rsa

Host development
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/development-key.id_rsa

Then I copied public key to server:

cd ~/.ssh
vim authorized_keys // deleted contents of this file and copied my development-key.id_rsa.pub into it and saved file
cat authorized_keys // looked at contents to confirm it matched my development-key.id_rsa.pub

Then I tried to ssh into development server, but it asked for my password (rather than prompting for passphrase).

So next I began to troubleshoot why it didn't work. I checked the file/directory permissions on server:

$ ls -l | grep home
drwxr-xr-x   6 root root  4096 Aug  7  2012 home
$ ls -l | grep myuser
drwxr-xr-x 16 myuser myuser  4096 Dec 22 17:47 myuser
$ ls -la | grep .ssh
drwx------  3 myuser myuser       4096 Dec 22 15:32 .ssh
~/.ssh $ ls -l | grep authorized_keys
-rw------- 1 myuser myuser  396 Dec 22 15:32 authorized_keys

Next I looked at the sshd_config file to confirm its configurations. Now I do not have password authentication disabled yet, but I don't have it disabled on my other server either and the ssh keys worked:

$ cd /etc/ssh
$ head -n 1000 sshd_config | grep 'PasswordAuthentication'
#PasswordAuthentication yes

I checked to see if any accounts were not allowed access to ssh (but there was nothing unusual here):

$ head -n 1000 sshd_config | grep 'AllowUsers'
$ head -n 1000 sshd_config | grep 'DenyUsers'

I made sure public key authentication was enabled:

head -n 1000 sshd_config | grep 'PubkeyAuthentication'
PubkeyAuthentication yes
$ head -n 1000 sshd_config | grep 'RSAAuthentication'
RSAAuthentication yes
RhostsRSAAuthentication no

I then restarted the ssh server:

sudo restart ssh

I then checked if my home directory is encrypted but it's not:

ls -A /home
.directory   lost+found  quota.group  someuser
myuser  passenger   quota.user

I checked perhaps there was some other configuration on the system:

/ $ locate sshd_config
/etc/ssh/sshd_config
/usr/share/doc/openssh-client/examples/sshd_config
/usr/share/man/man5/sshd_config.5.gz

I tried the suggestions here:

ssh no longer allows public key authentication

So finally I tried ssh in debug mode, and this is what I got (I changed the ip address and usernames):

ssh -vv [email protected]
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/viggy/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xx.xxx.xx.xxx [xx.xxx.xx.xxx] port 22.
debug1: Connection established.
debug1: identity file /home/viggy/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/viggy/.ssh/id_rsa-cert type -1
debug1: identity file /home/viggy/.ssh/id_dsa type -1
debug1: identity file /home/viggy/.ssh/id_dsa-cert type -1
debug1: identity file /home/viggy/.ssh/id_ecdsa type -1
debug1: identity file /home/viggy/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1 Debian-5ubuntu1.1
debug1: match: OpenSSH_5.9p1 Debian-5ubuntu1.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1.1
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: [email protected],[email protected],ssh-rsa,[email protected],[email protected],[email protected],[email protected],[email protected],ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: none,[email protected],zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[email protected],hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,[email protected],hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: none,[email protected]
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: sending SSH2_MSG_KEX_ECDH_INIT
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: RSA 42:f0:18:ae:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx
debug1: Host 'xx.xxx.xx.xxx' is known and matches the RSA host key.
debug1: Found key in /home/viggy/.ssh/known_hosts:3
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/viggy/.ssh/id_rsa (0xb8bab790)
debug2: key: viggy@teamviggy (0xb8bb1e18)
debug2: key: viggy@teamviggy (0xb8bb1cb8)
debug2: key: /home/viggy/.ssh/id_dsa ((nil))
debug2: key: /home/viggy/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/viggy/.ssh/id_rsa
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: viggy@teamviggy
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: viggy@teamviggy
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password
debug1: Trying private key: /home/viggy/.ssh/id_dsa
debug1: Trying private key: /home/viggy/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
[email protected]'s password:

UPDATE: So I used my public production key on my development server and that worked. So apparently something in my ~/.ssh/config file is incorrect but I am not sure what.

openssh

4 Answers

  1. ssh -vv [email protected]
OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /home/viggy/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *

    Applying options for * means that the ssh client thinks that the host you are connecting to is not in the config file.

    Based on your comments to the other answer you already moved every host specific setting to the top of the config file, before the "Host *" section, so parsing can't be a problem now.

    But the ssh client still can't find that host in the config file which can only mean that the Host which you wrote into the config file differ from the one which you wrote on the command line when you invoked ssh. Are you sure that the Host you wrote in the config file is EXACTLY the same as what you write on the command line? (It has to be exactly the same, names are not converted to a canonicalized host name before matching.)

    • 2

  2. I ran into this issue recently and it turned out to be an issue with SELinux being in enforcing mode and ~/.ssh and ~/.ssh/authorized_keys files having the wrong contexts.

    This surfaced in SElinux with the following audit2allow -a output after the ssh attempt from the client:

    #============= sshd_t ==============
allow sshd_t home_root_t:file { read getattr open };

    After running restorecon -Rv ~/.ssh reset the context on ~/.ssh and ~/.ssh/authorized_keys, were updated and ssh'ing in from the client no longer prompted for a password.

    Here's the page that led me to look at SELinux

    • 1

  3. Your config file is ordered backwards. I'm actually not sure if your client is even looking at your other keys but this:

    Host production
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/production-key.id_rsa

Host development
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/development-key.id_rsa

    Needs to be:

    Host development
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/development-key.id_rsa

Host production
HostName xx.xxx.xx.xxx
User myuser
IdentityFile ~/.ssh/production-key.id_rsa

    From the config file:

    Any configuration value is only changed the first time it is set. Thus, host-specific definitions should be at the beginning of the configuration file, and defaults at the end.

    But my second suggestion (should that fail as well, even if you put the development stuff ALLLLL the way at the top) - try moving all the other keys except the development pub/priv keys and the known_hosts from ~/.ssh.

    SSH looks like it's defaulting to id_rsa and id_rsa.pub even with your settings in here. So I'd rename the developement-key.id_rsa and corresponding pub to id_rsa and id_rsa.pub.

    • 0

  4. I had the same problem and I solved just today. In my case the reason why ssh still prompts for a password is that I generated a public key with a password... Solved generating a new public key with an empty password. Sometimes I just need to stop running for a while...

    • -3