Bug 466199 - SSH will not authenticate with PasswordAuthentication no
SSH will not authenticate with PasswordAuthentication no
Status: CLOSED DUPLICATE of bug 473014
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
9
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-08 22:23 EDT by Mike Frey
Modified: 2009-01-15 16:34 EST (History)
4 users (show)

See Also:
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: ---


Attachments (Terms of Use)

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.