0

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?

12
  • Did you copy id_rsa.pub and put it on the server's authorized_keys?
    – tom
    Commented Jun 13, 2013 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
    Commented Jun 13, 2013 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
    Commented Jun 13, 2013 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
    Commented Jun 13, 2013 at 2:17
  • Can you try changing AuthorizedKeysFile ~/.ssh/authorized_keys to AuthorizedKeysFile %h/.ssh/authorized_keys?
    – tom
    Commented Jun 13, 2013 at 2:20

5 Answers 5

1

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".

6
  • It doesn't look to be changed from the default to me. The setting there matched the last two sentences of your post.
    – pzkpfw
    Commented Jun 13, 2013 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 Commented Jun 13, 2013 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.
    – pzkpfw
    Commented Jun 13, 2013 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. Commented Jun 13, 2013 at 11:11
  • Then I understand, so maybe that was changed manually which broke it :)
    – pzkpfw
    Commented Jun 13, 2013 at 11:12
1

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.

2
  • 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
    Commented Jun 13, 2013 at 23:32
  • Now in CentOS7, if the .ssh folder is not set to 700, it rejects the public key authentication at all Commented Apr 6, 2015 at 5:19
1

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

0

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

SELINUX=enforcing

to

SELINUX=permissive
0

Another thing that can cause we did not send a packet, disable method is if the server is configured to reject your login. For example, if you try to log in as root when the configuration contains PermitRootLogin no.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .