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?

user2480068
  • 29
  • 1
  • 1
  • 2
  • Did you copy `id_rsa.pub` and put it on the *server's* `authorized_keys`? –  Jun 13 '13 at 01: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` –  Jun 13 '13 at 02: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? –  Jun 13 '13 at 02: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. –  Jun 13 '13 at 02:17
  • Can you try changing `AuthorizedKeysFile ~/.ssh/authorized_keys` to `AuthorizedKeysFile %h/.ssh/authorized_keys`? –  Jun 13 '13 at 02:20
  • Also, why is there an `id_rsa` on the remote machine? –  Jun 13 '13 at 02:47
  • md5 sums all match. Changed the config file as you suggested. Removed remote id_rsa. Still asking for pass, client is still offering local id_rsa with no reaction from the server, same as in OP. –  Jun 13 '13 at 09:11
  • Sorry, I am at a loss. Maybe somebody else can help you. –  Jun 13 '13 at 09:56
  • Thank you for your time. I guess I'll open a ticket with the VPS provider, but they won't be responding any time soon if anyone else wants to help. lol – user2480068 Jun 13 '13 at 10:08
  • Comment out that `AuthorizedKeysFile` line. – NickW Jun 13 '13 at 10:11
  • Just a few more things you may like to try: double check group and other don't have rwx permission on `.ssh` and `.ssh/*`, ssh from the remote to itself (localhost) using a public key, restart sshd and/or reboot, run sshd in a terminal with verbose debugging using `sshd -ddd` (kill it first or run it on a different port). Good luck. – tom Jun 13 '13 at 10:41
  • `PasswordAuthentication yes` should be actually set to `no` if you don't want to be asked for a Password. And, perhaps you should have also a look at `UsePAM` (and set it too to `no`). – Nikos Alexandris Dec 15 '15 at 16:04

5 Answers5

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

Nickolay Olshevsky
  • 136
  • 3
  • It doesn't look to be changed from the default to me. The setting there matched the last two sentences of your post. – pzkpfw 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. – pzkpfw 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 :) – pzkpfw Jun 13 '13 at 11:12
  • This was actually discussed in the comments above. It was set up with ~/.ssh/ out-of-the-box. I changed it to %h last night and it didn't work. – user2480068 Jun 13 '13 at 22:49
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.

user2480068
  • 29
  • 1
  • 1
  • 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 Jun 13 '13 at 23:32
  • Now in CentOS7, if the .ssh folder is not set to 700, it rejects the public key authentication at all – Musa Haidari Apr 06 '15 at 05: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.

Community
  • 1
buzz3791
  • 286
  • 2
  • 7
0

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

SELINUX=enforcing

to

SELINUX=permissive
slhck
  • 223,558
  • 70
  • 607
  • 592
user305969
  • 1
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.

starfry
  • 1,587
  • 15
  • 30