Bug 466199

Summary: SSH will not authenticate with PasswordAuthentication no
Product: [Fedora] Fedora Reporter: Mike Frey <mhfrey>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 9CC: agj, dwalsh, mgrepl, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-12 13:54:27 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Mike Frey 2008-10-08 22:23:12 EDT
Description of problem: I set up my server sshd_config file with "PasswordAuthentication no", created the necessary DSA key files and set the protections properly.  I cannot ssh back to the server.


Version-Release number of selected component (if applicable): openssh-5.1p1-2.fc9.i386, 


How reproducible: 100% of the time


Steps to Reproduce:
1. set "PasswordAuthentication no" in sshd_config file and restart sshd
2. create DSA keys, move public key to authorized_keys2, and set permissions
3. ssh 127.0.0.1
  
Actual results:

output from ssh -vvv 127.0.0.1
debug1: Next authentication method: publickey
debug1: Trying private key: /home/frey/.ssh/identity
debug3: no such identity: /home/frey/.ssh/identity
debug1: Trying private key: /home/frey/.ssh/id_rsa
debug3: no such identity: /home/frey/.ssh/id_rsa
debug1: Offering public key: /home/frey/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic).

cat of /var/log/secure with LogLevel DEBUG3
...temporarily_use_uid: 500/500 (e=0/0)
debug1: trying public key file /home/frey/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 500/500 (e=0/0)
debug1: trying public key file /home/frey/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for frey from 127.0.0.1 port 42313 ssh2
debug3: mm_answer_keyallowed: key 0xb8a562e8 is not allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-dss
Connection closed by 127.0.0.1
debug1: do_cleanup
debug3: PAM: sshpam_thread_cleanup entering
debug1: do_cleanup
debug1: PAM: cleanup
debug3: PAM: sshpam_thread_cleanup entering

Expected results:
connection to server via ssh and request for pass phrase

Additional info:  I have had this working before on an FC8 server and an RHEL4.0 server.
Comment 1 Tomas Mraz 2008-10-17 03:56:39 EDT
It seems that the server for some reasons cannot read the authorized_keys and authorized_keys2 files.
Does it work if you put SELinux into permissive mode?
Comment 2 Aubrey Jaffer 2009-01-09 18:23:47 EST
Putting SELINUX=permissive in /etc/selinux/config fixes the problem; RSA authentication now works.
Comment 3 Aubrey Jaffer 2009-01-09 18:29:25 EST
My success is with openssh sshd in Fedora-10.
Comment 4 Tomas Mraz 2009-01-12 05:41:19 EST
Could you try 

'restorecon -r -v -F ~<user>/.ssh'

Did it change any contexts? If so, does it now work in enforcing mode?
Comment 5 Aubrey Jaffer 2009-01-12 11:13:51 EST
Appended is the output from the command.  After running that command, I can now ssh to the host with SELINUX=enforcing.

[root@home etc]# restorecon -r -v -F ~jaffer/.ssh
restorecon reset /home/jaffer/.ssh context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/authorized_keys context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/known_hosts2 context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/known_hosts context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/config context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/authorized_keys2 context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/id_rsa.pub context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/id_dsa context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/id_rsa context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/anoncvs.key context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/id_dsa.pub context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
restorecon reset /home/jaffer/.ssh/random_seed context unconfined_u:object_r:home_root_t:s0->system_u:object_r:ssh_home_t:s0
Comment 6 Tomas Mraz 2009-01-12 13:54:27 EST
Dan, what do you think about this problem? This should at least warrant a FAQ entry somewhere. 

I understand that the intent was to not allow sshd to access any files in user and root home dirs except .ssh subdirectory, but I can see that this will get many duplicate bug reports - I've already seen some.

*** This bug has been marked as a duplicate of bug 473014 ***
Comment 7 Aubrey Jaffer 2009-01-12 14:20:41 EST
That the full debug output of ssh gives no hint of why the authentication failed, or even that it did fail, is a bug.
Comment 8 Tomas Mraz 2009-01-12 15:05:13 EST
No, not really - actually if it gave a hint it would be a security problem.
Comment 9 Daniel Walsh 2009-01-12 15:20:18 EST
Are you saying /var/log/secure or /var/log/messages was not indicating permission denied on  readying of the /home/jaffer/.ssh/  files?

What avc did you actually see?
Comment 10 Aubrey Jaffer 2009-01-12 17:18:45 EST
 | --- Comment #9 from Daniel Walsh <dwalsh@redhat.com>  2009-01-12 15:20:18 EDT ---
 | Are you saying /var/log/secure or /var/log/messages was not indicating
 | permission denied on  readying of the /home/jaffer/.ssh/  files?

/var/log/secure had no indication of the failures; and it didn't occur to me to look in /var/log/messages (which does have indications) for this sort of error.

 | What avc did you actually see?

If AVC is some SELinux thing, then the opportunity to examine it is long gone.  At the time, I had no idea that SELinux was responsible for the failure.
Comment 11 Daniel Walsh 2009-01-13 10:00:53 EST
That is strange the sshd/pam would not report permission denied in /var/log/secure?
Comment 12 Aubrey Jaffer 2009-01-15 13:59:39 EST
(In reply to comment #8)
> No, not really - actually if it gave a hint it would be a security problem.

That might be true if sshd behaved consistently with regards to the presence of valid public keys -- but it doesn't.  If "PasswordAuthentication" is "no" in /etc/ssh/sshd_config, then attempts to ssh as users lacking .ssh directories fails immediately, unlike the behavior when there is an .ssh directory but it lacks the requisite permissions on authorized_keys.

Failing immediately or returning a message about permissions would be no more of a  security problem that the behavior above.
Comment 13 Tomas Mraz 2009-01-15 14:26:41 EST
There are 2 things mixed up. If the problem is with the .ssh directory on the client side then the ssh -vvv should give hints what the problem is. On the other hand if the problem is with the .ssh directory on the server side, the ssh -vvv can not and should not receive any hints from the server. The ssh server should eventually write something to the /var/log/{secure,messages} on the server.
Comment 14 Aubrey Jaffer 2009-01-15 16:34:20 EST
(In reply to comment #13)
> There are 2 things mixed up. If the problem is with the .ssh directory on the
> client side then the ssh -vvv should give hints what the problem is. On the
> other hand if the problem is with the .ssh directory on the server side, the
> ssh -vvv can not and should not receive any hints from the server. The ssh
> server should eventually write something to the /var/log/{secure,messages} on
> the server.

I am not confusing the client and server sides.  If I ssh to a Fedora10 server having "PasswordAuthentication no" using a username who lacks a .ssh/ directory ON THE SERVER, then it immediately fails:

$ ssh martin@xxxxxxxx.us
reverse mapping checking getaddrinfo for wireless_broadband_router [xx.xxx.xx.xxx] failed - POSSIBLE BREAK-IN ATTEMPT!
Permission denied (publickey,gssapi-with-mic).

If I ssh to that same Fedora10 server with a username having a misconfigured .ssh/ directory ON THE SERVER, then it takes several minutes to fail.

With "PasswordAuthentication no", sshd violates your claim about not receiving any hints.