Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Trying to set up SSH to my CentOS VPS with key auth and no pass phrase so that I can auto-connect from my Debian 7 local server. I've gone as far as copying and pasting from two different guides on the net (here and here) and I still get asked for a password. (not pass phrase)

My remote sshd_config Authentication section, cut off just before the kerberos section:

    # Authentication:

#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile ~/.ssh/authorized_keys
#AuthorizedKeysCommand none
#AuthorizedKeysCommandRunAs nobody

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

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no
PasswordAuthentication yes

# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
ChallengeResponseAuthentication no

Remote /var/log/secure has no errors:

Jun 13 07:02:14 *remote host* sshd[4206]: Accepted password for admin from *my-ip* port 48919 ssh2
Jun 13 07:02:15 *remote host* sshd[4206]: pam_unix(sshd:session): session opened for user admin by (uid=0)
Jun 13 07:02:20 *remote host* sshd[4220]: Received disconnect from *my-ip*: 11: disconnected by user
Jun 13 07:02:20 *remote host* sshd[4206]: pam_unix(sshd:session): session closed for user admin

and verbose connecting on client has no errors, just sends private key and skips to password:

debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: *local/user/home*/.ssh/id_rsa ((nil))
debug2: key: *local/user/home*/.ssh/id_dsa ((nil))
debug2: key: *local/user/home*/.ssh/id_ecdsa ((nil))
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug2: we did not send a packet, disable method
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

debug1: Unspecified GSS failure.  Minor code may provide more information


debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found

debug2: we did not send a packet, disable method
debug1: Next authentication method: publickey
debug1: Trying private key: *local/user/home*/.ssh/id_rsa
debug1: read PEM private key done: type RSA
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Trying private key: *local/user/home*/.ssh/id_dsa
debug1: Trying private key: *local/user/home*/.ssh/id_ecdsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: password
admin@*remote server*'s password:

After reading suggestions and following the second guide, I've tried setting both 755 and 600 on everything in local and remote ~/.ssh/ directories, and it still doesn't work. As I said, I copied and pasted this command:

cat id_rsa.pub >> authorized_keys

to copy the key into the authorized_keys file; I copied and pasted all commands from both guides to ensure nothing is wrong in my configuration.

Any ideas?

share|improve this question

migrated from stackoverflow.com Jun 13 '13 at 10:01

This question came from our site for professional and enthusiast programmers.

    
Did you copy id_rsa.pub and put it on the server's authorized_keys? –  tom Jun 13 '13 at 1:55
    
yes. I've gone through the process 3 times now, deleting everything in local and remote ~/.ssh/ directories each time. The authorized_keys file exists only on the remote server; just did a ls to make sure: [admin@*remote host* ~]$ ls ~/.ssh/ authorized_keys id_rsa –  user2480068 Jun 13 '13 at 2:01
    
Is there a way to check the id_rsa against authorized_keys in a way that will plainly tell me if they match or not? I'm guessing the pub and private keys are different somehow, so I can't just compare, right? –  user2480068 Jun 13 '13 at 2:08
    
The only key in authorized_keys should be id_rsa.pub, so [local]$ md5sum id_rsa.pub and [remote]$ md5sum authorized_keys should give the same checksum. –  tom Jun 13 '13 at 2:17
    
Can you try changing AuthorizedKeysFile ~/.ssh/authorized_keys to AuthorizedKeysFile %h/.ssh/authorized_keys? –  tom Jun 13 '13 at 2:20
show 6 more comments

4 Answers

You have wrong value for AuthorizedKeysFile parameter. From man sshd_config:

AuthorizedKeysFile may contain tokens of the form %T which are substituted during connection set-up. The following tokens are defined: %% is replaced by a literal '%', %h is replaced by the home directory of the user being authenticated and %u is replaced by the username of that user. After expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory. The default is ".ssh/authorized_keys".

share|improve this answer
    
It doesn't look to be changed from the default to me. The setting there matched the last two sentences of your post. –  bigbadonk420 Jun 13 '13 at 10:55
    
Your sshd_config contains line: AuthorizedKeysFile ~/.ssh/authorized_keys which is wrong. It should ne %h/.ssh/authorized_keys or just commented out –  Nickolay Olshevsky Jun 13 '13 at 11:02
    
"AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory. The default is ".ssh/authorized_keys". <- are you saying that the default is the absolute path of /.ssh/authorized_keys? No, because it's interpreted as relative to the user's home directory as the documentation you just quoted states. –  bigbadonk420 Jun 13 '13 at 11:05
    
Default doesn't contain leading slash, so yes, it is related to user's home directory. BUT leading tilde will be interpreted to something else, most likely - to home of sshd user. –  Nickolay Olshevsky Jun 13 '13 at 11:11
    
Then I understand, so maybe that was changed manually which broke it :) –  bigbadonk420 Jun 13 '13 at 11:12
show 1 more comment

Thanks everyone for the help. I guess you all will hate to hear that it just magically fixed itself today. That's right: I woke up, installed some other software on the VPS, (some irssi-related things) rebooted, (even though I tried that last night, along with reloading the sshd service) went to log in to SSH to try some suggestions, and it gave me a new WARNING: UNPROTECTED PRIVATE KEY FILE! message. Since I've been doing chmod -R 755 .ssh/ lately on my local SSH files because 600 won't let it issue the key for some weird reason, I used chmod -R 700 .ssh/ after this warning and now everything works fine. I really don't know what happened. Again, thanks everyone for your time.

share|improve this answer
    
chmod 600 (rw-------) on the .ssh/ directory is wrong. Directories need to have the x bit set, so 700 (rwx------). Files within the directory would be fine at 600. –  Kent Jun 13 '13 at 23:32
add comment

If SELinux on the system, edit /etc/selinux/config and change

SELINUX=enforcing

to

SELINUX=permissive
share|improve this answer
add comment

Another solution for SELinux preventing sshd from reading $HOME/.ssh is to use restorecon, see my answser here http://superuser.com/a/764020/213743.

share|improve this answer
add 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.