Bug 473014 - (SSHKeyLabel) User key authentication fails in ssh from F10 client to F10 server
User key authentication fails in ssh from F10 client to F10 server
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
: 466199 476362 481079 491032 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2008-11-25 21:59 EST by Nick Urbanik
Modified: 2009-03-19 03:31 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-11-28 05:09:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Running /usr/sbin/sshd -ddd on laptop (17.28 KB, text/plain)
2008-11-26 15:35 EST, Nick Urbanik
no flags Details
Result of running ssh -vvv (11.11 KB, text/plain)
2008-11-26 15:37 EST, Nick Urbanik
no flags Details

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

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