1

I am able to log into my server with a password, but not with my public key. I'm running CentOS release 6.3 (Final) on a Rackspace.com server

I added my local ~/.ssh/id_rsa.pub to the remote server's ~/.ssh/authorized_keys and remote permissions seem okay.

$ ll -d .
drwxr-x---. 15 fort apache 4096 Feb 22 16:07 .
$ ll -d .ssh
drwx------. 2 fort apache 4096 Feb 17 19:40 .ssh
$ ll -d .ssh/authorized_keys
-rw-------. 1 fort fort 2034 Feb 18 06:06 .ssh/authorized_keys

I checked that the server is accepting public key authentication:

$ ssh -o PreferredAuthentications=none fort@fort
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive).

Connecting with -vvv shows the failure

$ ssh -vvv -o PreferredAuthentications=publickey fort@fort
OpenSSH_7.3p1, LibreSSL 2.4.1
debug1: Reading configuration data /Users/kim/.ssh/config
...
debug1: Connecting to cedar.greencitypartnerships.org [108.166.125.240] port 22.
debug1: Connection established.
... 
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred: 
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/kim/.ssh/id_rsa
debug3: send_pubkey_test
debug3: send packet: type 50
debug2: we sent a publickey packet, wait for reply
debug3: receive packet: type 51
...
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive).
$

This is all I see when tailing /var/log/secure on the server

# tail -f /var/log/secure
...
Feb 24 06:12:16 fort sshd[3064]: Connection closed by 97.113.252.17

Here is what I get tailing another server I --can-- log into

# tail -f /var/log/secure
...
Feb 23 22:14:12 cedar sshd[2187]: Accepted publickey for cedar from 192.168.56.1 port 53004 ssh2
Feb 23 22:14:12 cedar sshd[2187]: pam_unix(sshd:session): session opened for user cedar by (uid=0)

I then tried creating a public key on the server itself, adding it to the server's ~/.ssh/authorized_keys. I got the same failure

$ ssh -o PreferredAuthentications=publickey localhost
Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive).

and

# tail -f /var/log/secure
...
Feb 24 06:30:37 fort sshd[3841]: Connection closed by ::1

Next, I tried running sshd in debug mode on another port. I --was-- able to log in this time.

 # /usr/sbin/sshd -d -p 27

and on the same server ...

$ ssh -p 27 -o PreferredAuthentications=publickey localhost
Last login: Fri Feb 24 06:34:37 2017 from 97-113-252-17.tukw.qwest.net
Environment:
  LANG=en_US.UTF-8
  USER=fort
  ...
 $

To confirm that sshd did not start working because I was running in debug mode, I started it up normally. Again, I was able to successfully log in.

# /usr/sbin/sshd -p 27
# 

and

$ ssh -p 27 -o PreferredAuthentications=publickey localhost
Last login: Fri Feb 24 06:39:30 2017 from localhost
[fort@fort ~]$

and

# tail -f /var/log/secure
...
Feb 24 06:46:58 fort sshd[4595]: Server listening on 0.0.0.0 port 27.
Feb 24 06:46:58 fort sshd[4595]: Server listening on :: port 27.
Feb 24 06:48:13 fort sshd[4629]: Accepted publickey for fort from ::1 port 51302 ssh2
Feb 24 06:48:13 fort sshd[4629]: pam_unix(sshd:session): session opened for user fort by (uid=0)

I changed the LogLevel to DEBUG, and restarted sshd on both port 22 and 27.

Here's where the port 22 connection fails:

debug1: trying public key file /home/fort/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 502/502 (e=0/0)
debug1: trying public key file /home/fort/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for fort from ::1 port 44994 ssh2

Here's where the port 27 connection succeeds

debug1: trying public key file /home/fort/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /home/fort/.ssh/authorized_keys, line 6
Found matching RSA key: 8f:87:0e:15:b5:88:49:04:b7:34:79:9d:7e:c2:8d:fa

What might be allowing me to use public key authentication on port 27, but not port 22? Could there be alternate settings used by /etc/init.d/sshd? What should I try next to get public key authentication working on port 22?

  • Raise the sshd log verbosity on the server to debug and restart sshd. – user9517 Feb 24 '17 at 7:45
  • can you run nmap on the target ? – Tolsadus Feb 24 '17 at 7:53
  • I changed LogLevel to DEBUG as recommended by "is the English way" and added a diff to the original post. – user402253 Feb 24 '17 at 19:47
  • Why is your system years out of date? – Michael Hampton Feb 24 '17 at 21:15
1

Is the system running selinux in enforcing mode, if so have you restored context on the authorized_keys file?

SELinux can prevent sshd from reading an authorized_keys file when it has been modified.

| improve this answer | |
  • You are correct that SELinux is the culprit. "setenforce 0" allows me to ssh on port 22. I'll continue investigating and will try your recommendation. Thanks! – user402253 Feb 25 '17 at 2:12
-1

My ~/.ssh/authorized_keys SELinux type was configured incorrectly with httpd_sys_content_t. This was probably done because apache content was being served directly out of the home directory.

$ ls -lZ .ssh/authorized_keys
-rw-------. fort fort unconfined_u:object_r:httpd_sys_content_t:s0 .ssh/authorized_keys

The reason I was able to get ssh working on port 27 was that the process had type "unconfined_t", not "sshd_t".

$ ps axZ | grep /usr/sbin/sshd | grep -v grep
unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 505 ? Ss   0:00 /usr/sbin/sshd
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 942 ? Ss   0:00 /usr/sbin/sshd -p 27

Here's the fix. restorecon changes the type from httpd_sys_content_t back to ssh_home_t.

# restorecon -vR .ssh
restorecon reset /home/fort/.ssh context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:ssh_home_t:s0
restorecon reset /home/fort/.ssh/authorized_keys context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:ssh_home_t:s0
restorecon reset /home/fort/.ssh/known_hosts context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:ssh_home_t:s0
restorecon reset /home/fort/.ssh/authorized_keys2 context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:ssh_home_t:s0
restorecon reset /home/fort/.ssh/id_rsa.pub context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:ssh_home_t:s0
restorecon reset /home/fort/.ssh/id_rsa context unconfined_u:object_r:httpd_sys_content_t:s0->unconfined_u:object_r:ssh_home_t:s0

Now ...

$ ssh -o PreferredAuthentications=publickey localhost Last login: Sat Feb 25 16:13:45 2017 from 97-113-252-17.tukw.qwest.net [fort@fort ~]$

| improve this answer | |
  • When you finally get round to updating your (very) out of date system, other port related SELinux delights await you. – user9517 Feb 27 '17 at 20:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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