Red Hat Bugzilla – Bug 473014
User key authentication fails in ssh from F10 client to F10 server
Last modified: 2009-03-19 03:31:38 EDT
Description of problem: I have used public key user authentication for many years. After my yum upgrade from rawhide to f10, public key authentication fails. I have verified that the appropriate keys are in the agent with ssh-add -l I have re-checked the fingerprints in the ~/.ssh/authorized_keys file on the remote machine, and verified that they match the fingerprint displayed with ssh-add -l. I have made the home directories in both the local and remote machines have permission 0700. I have also ensured that the ~/.ssh directory on both the local and remote machine have permission 0700. I have verified that all the files in ~/.ssh on both the local and remote machines have permission 0600. The problem is also described here: http://fedora-sparks.blogspot.com/2008/09/updated-ssh-authentication-fail.html Version-Release number of selected component (if applicable): openssh-clients-5.1p1-3.fc10.i386 How reproducible: Steps to Reproduce: 1. Upgrade from rawhide to f10 using yum upgrade. 2. ssh to another machine, also running f10, where the user public key is correctly installed in the ~/.ssh/authorized_keys file. 3. See the prompt for the password. Actual results: Am prompted for the password. Expected results: Expect to be logged in, authenticated by the public user key, as has always worked previously. Additional info: The log in using the password is successful. However, there are some other machines for which I do not have the password, but have my key in the authorized_keys file. This may prevent me from doing my work.
Can you please attach debug logs from the client as well as server? Run the server as /usr/sbin/sshd -ddd And the client as ssh -vvv <user@server>
My install started cleanly from snapshot 3 and has simply been upgraded by yum. ssh + keys is working perfectly here.
Created attachment 324793 [details] Running /usr/sbin/sshd -ddd on laptop
Created attachment 324794 [details] Result of running ssh -vvv
Yes, I see that I can connect from the laptop to the desktop machine (the other way round). Need investigate the pam setup, the /etc/ssh*_config files further.
I do not see pubkey authentication failure in the log but rather some problem with PAM open session. Do you see anything related in /var/log/secure on the ssh server?
Only the sshd[...]: reverse mapping checking getaddrinfo for .... [...] failed - POSSIBLE BREAK-IN ATTEMPT! These have occurred in the logs for some time before this authentication problem arose.
When I turn off selinux on the laptop, the problem disappears. I have yum upgraded these machines through each Fedora release over many years. I will try relabelling the filesystems on these machines, and indicate here whether this solves the problem.
Do you see any related AVCs in ausearch -m AVC output?
Okay, it is solved by doing sudo restorecon -r ~/.ssh Here is some of the output of ausearch -m AVC before I did this: time->Fri Nov 28 20:10:40 2008 type=SYSCALL msg=audit(1227863440.638:683): arch=40000003 syscall=5 success=no exit=-13 a0=b8f08ef0 a1=8800 a2=0 a3=8800 items=0 ppid=1760 pid=12649 auid=4294967295 uid=0 gid=0 euid=500 suid=0 fsuid=500 egid=500 sgid=0 fsgid=500 tty=(none) ses=4294967295 comm="sshd" exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1227863440.638:683): avc: denied { search } for pid=12649 comm="sshd" name=".ssh" dev=sda6 ino=130817 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir
I suppose this is now solved for me. I think that others may still be bitten by this. Even doing sudo touch /.autorelabel and having the filesystem relabelled at the reboot did not solve the problem for me. I needed to change to the home directory and there do sudo restorecon -r .ssh Only then did the .ssh/* files' label change to system_u:object_r:ssh_home_t At least this bug gives people a solution to google for.
Ok I think I found the problem, that file should not become unlabeled_t on an upgrade, so in selinux-policy-3.5.13-31 I will get it labeled correctly.
Excellent work Daniel! Thank you.
*** Bug 476362 has been marked as a duplicate of this bug. ***
*** Bug 466199 has been marked as a duplicate of this bug. ***
*** Bug 481079 has been marked as a duplicate of this bug. ***
*** Bug 491032 has been marked as a duplicate of this bug. ***