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.
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?
Putting SELINUX=permissive in /etc/selinux/config fixes the problem; RSA authentication now works.
My success is with openssh sshd in Fedora-10.
Could you try 'restorecon -r -v -F ~<user>/.ssh' Did it change any contexts? If so, does it now work in enforcing mode?
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
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 ***
That the full debug output of ssh gives no hint of why the authentication failed, or even that it did fail, is a bug.
No, not really - actually if it gave a hint it would be a security problem.
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 #9 from Daniel Walsh <dwalsh> 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.
That is strange the sshd/pam would not report permission denied in /var/log/secure?
(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.
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.
(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 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.