Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have configured sshd to accept key-based ssh logins with LogLevel on DEBUG, and uploaded my public key to ~/.ssh.authorized_keys, where permissions are set as:

700 ~/.ssh 600 ~/.ssh/authorized_keys

From root, I can su - USERNAME. From the client I get Permission denied (publicly). From the server Here's how it is telling me that it "Could not open authorized keys '/home/USERNAME/.ssh/authorized_keys': Permission denied".

    Client protocol version 2.0; client software version OpenSSH_5.2
    match: OpenSSH_5.2 pat OpenSSH*
    Enabling compatibility mode for protocol 2.0
    Local version string SSH-2.0-OpenSSH_5.9p1 Debian-5ubuntu1
    permanently_set_uid: 105/65534 [preauth]
    list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
    SSH2_MSG_KEXINIT sent [preauth]
    SSH2_MSG_KEXINIT received [preauth]
    kex: client->server aes128-ctr hmac-md5 none [preauth]
    kex: server->client aes128-ctr hmac-md5 none [preauth]
    SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
    SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
    expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
    SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth]
    SSH2_MSG_NEWKEYS sent [preauth]
    expecting SSH2_MSG_NEWKEYS [preauth]
    SSH2_MSG_NEWKEYS received [preauth]
    KEX done [preauth]
    userauth-request for user USERNAME service ssh-connection method none [preauth]
    attempt 0 failures 0 [preauth]
    PAM: initializing for "USERNAME"
    PAM: setting PAM_RHOST to "USERHOSTNAME"
    PAM: setting PAM_TTY to "ssh"
    userauth_send_banner: sent [preauth]
    userauth-request for user USERNAME service ssh-connection method publickey [preauth]
    attempt 1 failures 0 [preauth]
    test whether pkalg/pkblob are acceptable [preauth]
    Checking blacklist file /usr/share/ssh/blacklist.RSA-4096
    Checking blacklist file /etc/ssh/blacklist.RSA-4096
    temporarily_use_uid: 1001/1002 (e=0/0)
    trying public key file /home/USERNAME/.ssh/authorized_keys
    Could not open authorized keys '/home/USERNAME/.ssh/authorized_keys': Permission denied
    restore_uid: 0/0
    temporarily_use_uid: 1001/1002 (e=0/0)
    trying public key file /home/USERNAME/.ssh/authorized_keys2
    Could not open authorized keys '/home/USERNAME/.ssh/authorized_keys2': Permission denied
    restore_uid: 0/0
    Failed publickey for USERNAME from IPADDRESS port 57523 ssh2
    Connection closed by IPADDRESS [preauth]
    do_cleanup [preauth]
    monitor_read_log: child log fd closed
    do_cleanup
    PAM: cleanup
share|improve this question
1  
What is the ownership of .ssh? Can you make sure by chown -R USERNAME .ssh? –  johnshen64 Jun 19 '12 at 12:50
    
And what is the ownership of authorized_keys? –  Dmitri Chubarov Jun 19 '12 at 13:03
    
I'm assuming you can SSH normally, providing the password. It's just a problem with your SSH keys. This may help you... serverfault.com/questions/396935/… –  Ash Jun 19 '12 at 13:36
add comment

4 Answers

chown 1001:1002 /home/USERNAME/.ssh/authorized_keys
share|improve this answer
    
In further details, based on the logs, it looks like the user your are trying to SSH has isn't the owner of the .ssh directory and or files. You might also need to set the correct user:group on the /home/USERNAME/.ssh directory –  Ryan Gibbons Jul 5 '12 at 1:28
add comment

For me /usr/NX/home/nx/.ssh/authorized_keys was wrongly named /usr/NX/home/nx/.ssh/authorized_keys2 even after reinstallation. Here is how I fixed it:

/usr/NX/home/nx/.ssh # cp authorized_keys2 authorized_keys
/usr/NX/home/nx/.ssh # chown nx authorized_keys

I blogged about it at http://www.linuxintro.org/wiki/Nx#The_NX_service_is_not_available

share|improve this answer
add comment

It is not your own user that accesses those files, so 600 and 700 is not going to work. Plus, there's no need to secure it like that; there's nothing secure in authorized_keys.

share|improve this answer
2  
it is actually in the context of the connecting user that sshd reads authorized_keys and if authentication successful proceeds to create a virtual terminal. With correct ownership 0600 should work. –  Dmitri Chubarov Jun 19 '12 at 13:07
add comment

Your permissions are wrong:

chmod 755 /home/USERNAME/.ssh
chmod 644 /home/USERNAME/.ssh/authorized_keys
share|improve this answer
    
For security reasons, with default config, OpenSSH will ignore authorized_keys file with globally and group read permissions on .ssh or .ssh/authorized_keys –  Ryan Gibbons Jul 4 '12 at 20:13
    
I have to disagree with you, I took those permissions from my home directory, it works fine. –  Sirch Jul 4 '12 at 23:23
    
Feel free, here it is in their FAQ. openssh.org/faq.html#3.14 And here is the sshd_config man page. manpagez.com/man/5/sshd_config Specifies whether sshd(8) should check file modes and ownership of the user's files and home directory before accepting login. This is normally desirable because novices sometimes accidentally leave their directory or files world-writable. The default is ``yes''. Note that this does not apply to ChrootDirectory, whose permissions and ownership are checked unconditionally. –  Ryan Gibbons Jul 5 '12 at 1:25
1  
But 755 and 644 are not group/world writable. And indeed, I have these too and it works fine with StrictModes enabled. –  b0fh Jul 5 '12 at 8:03
    
Thank you for the man page, 755 is rwxr-xr-x, 644 is rw-r--r--, neither of which is writeable by anyone other than yourself, and fine for sshd. –  Sirch Jul 5 '12 at 13:04
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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