3

I have a strange issue with SSH public keys. There's one account on the server where I've uploaded my public key to .ssh/authorized_keys and it works as expected (I can login with no password). Then there's an account on the same server where I've done the same (few times already), but it still asks me for a password to login.

The settings that match for those accounts are following:

  1. Directory permissions are correct .ssh directory's owner and group is user. Permission set to 0700
  2. .ssh/authorized_keys has user and group set to the correct user and permissions are 0600
  3. I've tried comparing the files they're exactly the same. And tried scp ~/.ssh/id_rsa.pub user@server.com:.ssh/authorized_keys few times.

If I try to add -v to the ssh connection I get the following info for the one that's NOT WORKING:

OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007  
debug1: Reading configuration data /Users/pacis/.ssh/config  
debug1: Reading configuration data /opt/local/etc/ssh/ssh_config  
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.  
debug1: Connection established.  
debug1: identity file /Users/pacis/.ssh/identity type -1  
debug1: identity file /Users/pacis/.ssh/id_rsa type 1  
debug1: identity file /Users/pacis/.ssh/id_dsa type -1  
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5  
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*  
debug1: Enabling compatibility mode for protocol 2.0  
debug1: Local version string SSH-2.0-OpenSSH_4.7  
debug1: SSH2_MSG_KEXINIT sent  
debug1: SSH2_MSG_KEXINIT received  
debug1: kex: server->client aes128-cbc hmac-md5 none  
debug1: kex: client->server aes128-cbc hmac-md5 none  
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent  
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP  
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent  
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY  
debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the RSA host key.  
debug1: Found key in /Users/pacis/.ssh/known_hosts:40  
debug1: ssh_rsa_verify: signature correct  
debug1: SSH2_MSG_NEWKEYS sent  
debug1: expecting SSH2_MSG_NEWKEYS  
debug1: SSH2_MSG_NEWKEYS received  
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: Offering public key: /Users/pacis/.ssh/id_rsa  
debug1: Authentications that can continue: publickey,password  
debug1: Trying private key: /Users/pacis/.ssh/identity  
debug1: Trying private key: /Users/pacis/.ssh/id_dsa  
debug1: Next authentication method: password

And here's the same from the one that's working as expected:

OpenSSH_4.7p1, OpenSSL 0.9.8g 19 Oct 2007  
debug1: Reading configuration data /Users/pacis/.ssh/config  
debug1: Reading configuration data /opt/local/etc/ssh/ssh_config  
debug1: Connecting to xxx.xxx.xxx.xxx [xxx.xxx.xxx.xxx] port 22.  
debug1: Connection established.  
debug1: identity file /Users/pacis/.ssh/identity type -1  
debug1: identity file /Users/pacis/.ssh/id_rsa type 1  
debug1: identity file /Users/pacis/.ssh/id_dsa type -1  
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5  
debug1: match: OpenSSH_5.1p1 Debian-5 pat OpenSSH*  
debug1: Enabling compatibility mode for protocol 2.0  
debug1: Local version string SSH-2.0-OpenSSH_4.7  
debug1: SSH2_MSG_KEXINIT sent  
debug1: SSH2_MSG_KEXINIT received  
debug1: kex: server->client aes128-cbc hmac-md5 none  
debug1: kex: client->server aes128-cbc hmac-md5 none  
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent  
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP  
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent  
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY  
debug1: Host 'xxx.xxx.xxx.xxx' is known and matches the RSA host key.  
debug1: Found key in /Users/pacis/.ssh/known_hosts:40  
debug1: ssh_rsa_verify: signature correct  
debug1: SSH2_MSG_NEWKEYS sent  
debug1: expecting SSH2_MSG_NEWKEYS  
debug1: SSH2_MSG_NEWKEYS received  
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: Offering public key: /Users/pacis/.ssh/id_rsa  
debug1: Server accepts key: pkalg ssh-rsa blen 277  
debug1: Authentication succeeded (publickey).  
debug1: channel 0: new [client-session]  
debug1: Entering interactive session

Here's the /etc/ssh/sshd_config:

Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes

The last info I can think of that's relative it's ls -la of both accounts home dirs and .ssh dirs.

Working one:

total 40
drwxr-x--- 5 user1 www-data 4096 2009-10-29 22:11 .
drwxr-x--x 6 root  www-data 4096 2009-10-27 23:09 ..
....
drwx------ 2 user1 user1    4096 2009-10-23 07:20 .ssh

total 12
drwx------ 2 user1 user1   4096 2009-10-23 07:20 .
drwxr-x--- 5 user1 www-data 4096 2009-10-29 22:11 ..
-rw------- 1 user1 user1    413 2009-10-23 07:20 authorized_keys

Not working one:

total 68
drwxrwxr--  6 user2 www-data    4096 2009-11-07 12:13 .
drwxr-x--x  5 root  root            4096 2009-10-09 14:29 ..
....
drwx------  2 user2 user2       4096 2009-11-07 15:52 .ssh

total 12
drwx------ 2 user2 user2 4096 2009-11-08 20:32 .
drwxrwxr-- 6 user2 www-data     4096 2009-11-07 12:13 ..
-rw------- 1 user2 user2  412 2009-11-07 09:55 authorized_keys

I have no clue whatsoever why it's not working and I've checked and doublechecked everything several times already. What am I missing?

Thank you for your time.

Improve this question
8
  • Given the limited information you've given and the fact you appear to vote down any answer you think is irrelevant... Does the server have all users configured locally in /etc/passwd or does it use any remote authentication via PAM (LDAP, ADS, etc)? Have you verified that the md5sum of the authorized_keys file is identical on both accounts?
    – Jeremy Bouse
    Nov 8, 2009 at 0:18
  • You've specified that you checked the ~user/.ssh directory permissions, but the ~user directory also must be protected. Write must be disallowed for group and other. Otherwise malicious_user could place their own contents in ~user/.ssh and gain access to your account.
    – Alex
    Nov 8, 2009 at 3:24
  • @Jeremy: Why shouldn't he downvote answers that are "not useful" (the definition of the downvote button as shown in the mouseover)?
    – womble ♦
    Nov 8, 2009 at 5:27
  • @womble, cause 9 times out of 10 this problem is regarding either ownership or permissions of the files or directories as others have suggested. As the OP says other accounts work then it's not system configuration related unless it's PAM related for remote user account which I've seen happen before. In either event the OP hasn't shown enough to really assist him.
    – Jeremy Bouse
    Nov 8, 2009 at 5:38
  • @Jeremy: Way to not answer the question.
    – womble ♦
    Nov 8, 2009 at 6:03

6 Answers 6

Reset to default
3

Try removing the group write access to the user2 home directory on the account that's not working... If anyone has write access other than the account user SSH will complain. If you look at the directory listings posted the working one has:

drwxr-x--- 5 user1 www-data 4096 2009-10-29 22:11 ..

The non-working account has:

drwxrwxr-- 6 user2 www-data     4096 2009-11-07 12:13 ..

As I stated in my earlier comments to the original question 9 times out of 10 this is a permissions/ownership issue. Once the information was provided this is made apparently obvious.

Looking at one of my own accounts I get the following:

$ ls -lnd .
drwxr-xr-x 14 97037 97037 4096 Nov  8 09:31 .
$ ls -lnd .ssh
drwx------ 2 97037 97037 4096 Jun 16 11:30 .ssh
$ ls -lnd .ssh/authorized_keys 
-rw------- 1 97037 97037 388 Jun 16 11:30 .ssh/authorized_keys

I can only imagine the group membership to www-data is a mis-guided way of restricting access to the home directory while allowing Apache to serve web pages inside the users directory.

Furthermore cawer's suggestion was given a summary dismissal for suggesting the permissions on the ~/.ssh directory stating that all the permissions were correct and identical but the proof provided shows otherwise.

Since proof is in the pudding... Here's the ssh connection log to my account:

$ ssh -v example.com
OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/jbouse/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to example.com [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/jbouse/.ssh/keys.d/id_rsa.example type -1
debug1: identity file /home/jbouse/.ssh/keys.d/id_dsa.example type -1
debug1: identity file /home/jbouse/.ssh/keys.d/jbouse@example type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'example.com' is known and matches the RSA host key.
debug1: Found key in /home/jbouse/.ssh/known_hosts:85
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
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/jbouse/.ssh/keys.d/id_rsa.example
debug1: Trying private key: /home/jbouse/.ssh/keys.d/id_dsa.example
debug1: Trying private key: /home/jbouse/.ssh/keys.d/jbouse@example
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8

If I then run the following to set my home directories permissions the same as your user2 account:

$ ls -lnd .
drwxr-xr-x 14 97037 97037 4096 Nov  8 09:31 .
$ chmod g+w .
$ ls -lnd .
drwxrwxr-x 14 97037 97037 4096 Nov  8 09:31 .

Finally try to connect again and I get the following ssh log:

$ ssh -v example.com
OpenSSH_5.1p1 Debian-6ubuntu2, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /home/jbouse/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to example.com [x.x.x.x] port 22.
debug1: Connection established.
debug1: identity file /home/jbouse/.ssh/keys.d/id_rsa.example type -1
debug1: identity file /home/jbouse/.ssh/keys.d/id_dsa.example type -1
debug1: identity file /home/jbouse/.ssh/keys.d/jbouse@example type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'example.com' is known and matches the RSA host key.
debug1: Found key in /home/jbouse/.ssh/known_hosts:85
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
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/jbouse/.ssh/keys.d/id_rsa.example
debug1: Trying private key: /home/jbouse/.ssh/keys.d/id_dsa.example
debug1: Trying private key: /home/jbouse/.ssh/keys.d/jbouse@example
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

When I change the permissions back by removing the group write permissions I can once again log into the account.

Improve this answer
3
  • I do really appreciate your help. I know I was being tough on my part, by stating that everything is correct, but that's my previous experience to blame. All the tutorials about public key setup that I've read talk only about permissions on ~/.ssh/ and ~/.ssh/authorized_keys permissions so this led me to believe that I was right. I'm sorry for not really listening to the words that were being said.
    – Rytis Lukoševičius
    Nov 9, 2009 at 4:31
  • As cavver had said SSH is quite fussy about broken permissions and that was my initial conclusion as well. Just took getting you to provide more information to show that and which directory ~/.ssh, ~/.ssh/authorized_keys or ~ that was at fault.
    – Jeremy Bouse
    Nov 9, 2009 at 11:38
  • I had the exact same problem, and the group write permissions on the home folder was what fixed it.
    – Apreche
    Nov 14, 2009 at 19:46
1

Check permissions for the folder .ssh on the server you are trying to login. Run chmod -R 600 .ssh. Ssh is fussy when it comes to broken permissions and public keys.

Improve this answer
2
  • As I've mentioned in the beggining all permissions are correct. I've tried what you suggest but that didn't help.
    – Rytis Lukoševičius
    Nov 7, 2009 at 13:49
  • -1 for not reading the question.
    – womble ♦
    Nov 8, 2009 at 0:01
1

You've checked all the common candidates for key authentication failure; the next thing I'd be doing is bumping up the logging level on the server and checking out /var/log/auth.log to see what it's reporting differently for the two logins.

Another thing worth clarifying -- on the account where it asks for the password, if you enter the password does it work and allow you to login? If PAM restrictions deny login for a particular account (and you've configured SSH to use PAM) you can get this sort of result, because for password auth the other PAM restrictions aren't checked until after you've entered the password.

Improve this answer
0

Your "authorized_keys" file can have a different name. Check it out:

cat /etc/ssh/sshd_config | grep AuthorizedKeys
#AuthorizedKeysFile     %h/.ssh/authorized_keys

If it's not overriden, check permissions for that file, and its directory: it must be readable for the user that you're logging into.

Improve this answer
1
  • it says exactly that in sshd_config and also I do have another account that's working on the same server.
    – Rytis Lukoševičius
    Nov 7, 2009 at 13:50
0

Is this a Debian system? If so the user that doesn't work may have a weak key.

See the Debian wiki for how to test your keys.

If you've got a weak key you'll have to upgrade the ssh packages on the client system and re-generate the keys for the user with the issue.

Improve this answer
-1 
ln -s authorized_keys authorized_keys2

usually solved the problem for me. note that IIRC the documentation discourages this.

Improve this answer
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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