Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

(This question had been erroneously asked in stack overflow -- I'm sorry for that -- and closed as "off topic")

I have no clue on how this happens. The distro is Scientific Linux 6.1 and everything is set up to perform authentication via public key. Yet, when sshd is running as a daemon (service sshd start), it doesn't accept public keys. (To obtain this piece of log, I've changed the sshd script to add the -ddd option)

debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug3: mm_answer_keyallowed: key 0x7f266e1a8840 is not allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug3: Wrote 64 bytes for a total of 1853
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 1

If sshd is run in debug mode (/usr/sbin/sshd -ddd), authentication works like a charm:

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: d7:3a:08:39:f7:28:dc:ea:f3:71:7c:23:92:02:02:d8
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f85527ef230 is allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug3: Wrote 320 bytes for a total of 2109
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0

Any ideas?? Has anyone seen anything like this?

Notes:

File permissions have been double checked:

# ll -d .ssh
drwx------. 2 root root 4096 Oct 14 10:05 .ssh
# ll .ssh
total 16
-rw-------. 1 root root  786 Oct 14 09:35 authorized_keys
-rw-------. 1 root root 1675 Oct 13 08:24 id_rsa
-rw-r--r--. 1 root root  393 Oct 13 08:24 id_rsa.pub
-rw-r--r--. 1 root root  448 Oct 13 12:51 known_hosts

I was asked if sshd can access root's files in "daemon mode". The closest answer I get to this question is:

# netstat -ntap | grep 22
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      19847/sshd 
# ps -ef | grep 19847
root     19847     1  0 09:58 ?        00:00:00 /usr/sbin/sshd

If sshd is running as root, I don't know how it's not possible to access its own files. Could SELinux be the cause?

share|improve this question
1  
Does the sshd init script do anything interesting? (Should be /etc/init.d/sshd?) that you're not doing on the command line? Instead of 'service sshd start' try 'sh -x /etc/init.d/ssh start'. –  P.T. Oct 14 '11 at 17:18

2 Answers 2

up vote 25 down vote accepted

Yes, SELinux is likely the cause. The .ssh dir is probably mislabeled. Look at /var/log/audit/audit.log. It should be labeled ssh_home_t. Check with ls -laZ. Run restorecon -r -vv /root/.ssh if need be.

share|improve this answer
    
Yep, SELinux was the cause: type=AVC msg=audit(1318597097.413:5447): avc: denied { read } for pid=19849 comm="sshd" name="authorized_keys" dev=dm-0 ino=262398 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file It works after running "restorecon -r -vv /root/.ssh". Thanks a lot. –  user666412 Oct 14 '11 at 19:44
1  
thanks THANKS THANKS for the selinux command line fix I've been trying to find for ages why it was I could ssh as root to my redhat enterprise 6.2 server using ssh key authentication, but I couldn't ssh in as a non-root user without having to enter a password. "ssh -v" didn't indicate anything unusual at all. I'd checked and rechecked the file protections on /home/example/.ssh It wasn't until I ran "/usr/sbin/sshd -d" and for some reason that worked normally that I realised something else was happening, and tried a different google search and found this. So, the symptoms were I could ssh as ro –  Paul M Jun 29 '12 at 13:05
    
Thank you! This was driving me crazy! For posterity, can you explain better what restorecon -r -vv /root/.ssh is doing to fix this? –  Stefan Lasiewski Sep 24 '13 at 19:05
    
Thanks, neither ssh -vvv nor LogLevel VERBOSE in sshd.conf points to SELinux. –  count0 Jun 2 at 20:52
    
I had to do this on the whole filesystem, i.e. restorecon -r /, YMMV. –  Irfy Oct 15 at 11:18

It looks like you use different keys when testing the connections, 0x7f266e1a8840 vs 0x7f85527ef230. Try connecting using 'ssh -v example.com' to sshd running as a daemon and in debug mode and look for the keys used by ssh around the string "Offering RSA public key".

share|improve this answer
    
Yes, there were id_rsa and id_dsa. DSA key is gone and I'll redo the test. –  user666412 Oct 14 '11 at 19:16
    
The value mentioned in debug3: mm_answer_keyallowed: key 0xFFFFFFFFFF will change every time the sshd receives a new connection. To confim this, find a server where SSH does work, crank up the sshd LOGLEVEL to debug3, restart sshd, run tail -f /var/log/secure |grep mm_answer_keyallowed and then log in a few times, waiting a few seconds (or minutes) between each connection. You'll see that the value changes each time. And actually it looks like a counter to me. –  Stefan Lasiewski Sep 24 '13 at 18:47

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.