Bug 473014 (SSHKeyLabel)

Summary: User key authentication fails in ssh from F10 client to F10 server
Product: [Fedora] Fedora Reporter: Nick Urbanik <nicku>
Component: opensshAssignee: Tomas Mraz <tmraz>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: medium    
Version: 10CC: daw-redhatbugzilla, dusha, dwalsh, joe, lists, mgrepl, mhfrey, nicku, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-28 05:09:40 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
Running /usr/sbin/sshd -ddd on laptop
Result of running ssh -vvv none

Description Nick Urbanik 2008-11-25 21:59:13 EST
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:

Version-Release number of selected component (if applicable):


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.
Comment 1 Tomas Mraz 2008-11-26 03:34:14 EST
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>
Comment 2 Anne 2008-11-26 13:54:53 EST
My install started cleanly from snapshot 3 and has simply been upgraded by yum.  ssh + keys is working perfectly here.
Comment 3 Nick Urbanik 2008-11-26 15:35:54 EST
Created attachment 324793 [details]
Running /usr/sbin/sshd -ddd on laptop
Comment 4 Nick Urbanik 2008-11-26 15:37:10 EST
Created attachment 324794 [details]
Result of running ssh -vvv
Comment 5 Nick Urbanik 2008-11-26 15:46:07 EST
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.
Comment 6 Tomas Mraz 2008-11-26 17:27:51 EST
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?
Comment 7 Nick Urbanik 2008-11-26 18:47:19 EST
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.
Comment 8 Nick Urbanik 2008-11-27 15:06:02 EST
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.
Comment 9 Tomas Mraz 2008-11-27 15:55:58 EST
Do you see any related AVCs in ausearch -m AVC output?
Comment 10 Nick Urbanik 2008-11-28 05:03:36 EST
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
Comment 11 Nick Urbanik 2008-11-28 05:09:40 EST
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.
Comment 12 Daniel Walsh 2008-12-04 09:22:18 EST
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.
Comment 13 Nick Urbanik 2008-12-04 15:07:11 EST
Excellent work Daniel!  Thank you.
Comment 14 Tomas Mraz 2008-12-15 03:33:27 EST
*** Bug 476362 has been marked as a duplicate of this bug. ***
Comment 15 Tomas Mraz 2009-01-12 13:54:27 EST
*** Bug 466199 has been marked as a duplicate of this bug. ***
Comment 16 Tomas Mraz 2009-02-12 10:48:22 EST
*** Bug 481079 has been marked as a duplicate of this bug. ***
Comment 17 Tomas Mraz 2009-03-19 03:31:38 EDT
*** Bug 491032 has been marked as a duplicate of this bug. ***