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?

Improve this question
4
  • Raise the sshd log verbosity on the server to debug and restart sshd. Commented Feb 24, 2017 at 7:45
  • can you run nmap on the target ? Commented Feb 24, 2017 at 7:53
  • I changed LogLevel to DEBUG as recommended by "is the English way" and added a diff to the original post. Commented Feb 24, 2017 at 19:47
  • Why is your system years out of date? Commented Feb 24, 2017 at 21:15

2 Answers 2

Reset to default
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
1
  • 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! Commented Feb 25, 2017 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
1
  • When you finally get round to updating your (very) out of date system, other port related SELinux delights await you. Commented Feb 27, 2017 at 20:51

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.