Bug 739989

Summary: ssh-copy-id command should call restorecon if available on target machine
Product: [Fedora] Fedora Reporter: Jan Pokorný <jpokorny>
Component: opensshAssignee: Petr Lautrbach <plautrba>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: dwalsh, jchadima, mattias.ellert, mgrepl, michael, plautrba, sgraf, tmraz
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openssh-5.8p2-22.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-26 18:10:04 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Jan Pokorný 2011-09-20 11:52:48 EDT
Using common ssh-keygen + ssh-copy-id way, I was not able to create
passwordless SSH connection between Fedora 16 (client) and RHEL 6 (server).
Entering password still worked well, but the desired behavior was different.

I tried many things trying to solve this, but to no avail.
Then I tried to apply ssh-keygen + ssh-copy-id sequence on another RHEL 6 box
and, to my big surprise, it started to work.

In the end, I discovered that the problem involves SELinux (standard enforcing
mode on each machine).  Diffing /usr/bin/ssh-copy-id file Fedora vs. RHEL,
Fedora's version apparently missing "restorecon" call.  Calling (e.g.)
"restorecon -R ~/.ssh" manually on the RHEL machine would help in my scenario,
still it is only a workaround that should be fixed with adding "restorecon"
call in a RHEL's way (testing that respective binary exists first).


Version-Release number of selected component (if applicable):
$ rpm -qf $(which ssh-copy-id)
openssh-clients-5.8p2-16.fc16.1.x86_64
Comment 1 Jan Pokorný 2011-09-20 13:38:08 EDT
This seems to be problem with Fedora 16 only (+ maybe rawhide).

Version in openssh-clients-5.6p1-34.fc15.1.x86_64 seems to be okay.
Comment 2 Stanislav Graf 2011-10-20 08:30:47 EDT
*** Bug 747527 has been marked as a duplicate of this bug. ***
Comment 3 Tomas Mraz 2011-10-20 09:00:23 EDT
Do you have latest SELinux policy installed?

It should no longer be necessary to call the restorecon.
Comment 4 Stanislav Graf 2011-10-20 15:09:59 EDT
Yes, latest selinux. Here is detailed scenario with selinux denying read to authorized keys:

[fedora16 ~]$ getenforce 
Enforcing
[fedora16 ~]$ rpm -qa | grep selinux
libselinux-utils-2.1.5-5.1.fc16.x86_64
libselinux-python-2.1.5-5.1.fc16.x86_64
libselinux-devel-2.1.5-5.1.fc16.x86_64
selinux-policy-3.10.0-43.fc16.noarch
libselinux-2.1.5-5.1.fc16.x86_64
libselinux-2.1.5-5.1.fc16.i686
selinux-policy-targeted-3.10.0-43.fc16.noarch
[fedora16 ~]$ ssh root@rhel6
[rhel6 ~]# yum update
No Packages marked for Update
[rhel6 ~]# rm -rf .ssh
[rhel6 ~]# logout
[fedora16 ~]$ ssh-copy-id root@rhel6
root@rhel6's password: 
ecode=0
[fedora16 ~]$ ssh root@rhel6
root@rhel6's password: 
[rhel6 ~]# ls -lZ .ssh/authorized_keys 
-rw-------. root root unconfined_u:object_r:admin_home_t:s0 .ssh/authorized_keys
[rhel6 ~]# rpm -qa | grep selinux
libselinux-python-2.0.94-5.el6.x86_64
libselinux-utils-2.0.94-5.el6.x86_64
selinux-policy-3.7.19-93.el6_1.7.noarch
selinux-policy-targeted-3.7.19-93.el6_1.7.noarch
libselinux-2.0.94-5.el6.x86_64
[rhel6 ~]# getenforce 
Enforcing
[rhel6 ~]# grep AVC /var/log/audit/audit.log
type=AVC msg=audit(1319137658.840:210): avc:  denied  { read } for  pid=2709 comm="sshd" name="authorized_keys" dev=vda1 ino=150423 scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:admin_home_t:s0 tclass=file
Comment 5 Tomas Mraz 2011-10-20 15:55:15 EDT
Ah, so you're doing ssh-copy-id from F16 to RHEL6 system. Then that makes sense that it is missing the restorecon call, because on RHEL6 it still has to be called. Perhaps the restorecon should not have been removed from the F16 ssh-copy-id yet.
Comment 8 Daniel Walsh 2011-11-15 09:07:59 EST
You should be running the RHEL6.2 policy on the server.  Currently this is

selinux-policy-3.7.19-126.el6
Comment 9 Daniel Walsh 2011-11-15 09:09:23 EST
sshd is in charge of creating this file/directory on the server.  The selinux-policy on the client, (the client does not even need to be running SELinux) does not matter.

The latest policy should do a file transition rule when sshd_t creates a directory in admin_home_t to ssh_home_t.
Comment 10 Stanislav Graf 2011-11-16 09:29:20 EST
New user doesn't have this directory:
[rhel62 ~]# useradd --home-dir /home/testuser testuser
ecode=0
[rhel62 ~]# ls -ldZ /home/testuser/.ssh
ls: cannot access /home/testuser/.ssh: No such file or directory
ecode=2

And my reproduction scenario still doesn't work - using selinux-policy from comment 8 :

[fedora16 ~]$ getenforce
Enforcing
ecode=0
[fedora16 ~]$ rpm -q selinux-policy
selinux-policy-3.10.0-55.fc16.noarch
ecode=0
[fedora16 ~]$ ssh root@rhel62
Last login: Wed Nov 16 15:16:06 2011 from fedora16
ecode=0
[rhel62 ~]# rpm -q selinux-policy
selinux-policy-3.7.19-126.el6.noarch
ecode=0
[rhel62 ~]# rm -rf .ssh
ecode=0
[rhel62 ~]# logout
Connection to rhel62 closed.
ecode=0
[fedora16 ~]$ ssh-copy-id root@rhel62
root@rhel62's password: 
Now try logging into the machine, with "ssh 'root@rhel62'", and check in:

  ~/.ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.

ecode=0
[fedora16 ~]$ ssh root@rhel62
root@rhel62's password: 
Last login: Wed Nov 16 15:16:55 2011 from fedora16
ecode=0
[rhel62 ~]# ls -lZ .ssh/authorized_keys
-rw-------. root root unconfined_u:object_r:admin_home_t:s0 .ssh/authorized_keys
[rhel62 ~]# getenforce 
Enforcing
ecode=0


Am I missing something?
Comment 11 Daniel Walsh 2011-11-16 16:53:28 EST
Looks like we have a bug.
Comment 12 Daniel Walsh 2011-11-16 17:13:06 EST
Jan when I do an ssh-copy-id what process creates the /root/.ssh directory? 

Does sshd do this or does it exec a second process?
Comment 13 Tomas Mraz 2011-11-18 02:31:52 EST
It is done by a regular login shell executed from the sshd.
Comment 14 Daniel Walsh 2011-11-18 09:51:31 EST
What command is executed?  So this is happening after pam_selinux and therefor the process is running as unconfined_t rather then sshd_t.  The polciy is handling sshd_t but can not handle unconfined_t or other users until Fedora 16.

If we executed the script without going through pam_selinux it would work.
Comment 15 Tomas Mraz 2011-11-18 12:02:29 EST
(In reply to comment #14)
> If we executed the script without going through pam_selinux it would work.

Unfortunately this is impossible as this would require to have a special SSH protocol message for that and we cannot add it to the standard.
Comment 16 Daniel Walsh 2011-11-18 12:50:38 EST
Tomas what program is it using to create and populate the directory?
Comment 17 Daniel Walsh 2011-11-18 14:30:32 EST
Tomas, I have finally gotten a clue.  sh-copy-id should still have the restorecon within the code.  (I never new ssh-copy-id was a simple script).  Since you do not know what the platform you will be ssh-copy-id into.  Only ssh-copy-id onto a F16 box will work.  If you are on f16 and ssh-copy-id onto an older SELinux box, it will not create the .ssh directory with the correct label.
Comment 18 Fedora Update System 2011-11-23 13:48:04 EST
openssh-5.8p2-22.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/openssh-5.8p2-22.fc16
Comment 19 Fedora Update System 2011-11-24 21:29:23 EST
Package openssh-5.8p2-22.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openssh-5.8p2-22.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2011-16389/openssh-5.8p2-22.fc16
then log in and leave karma (feedback).
Comment 20 Fedora Update System 2011-11-26 18:10:04 EST
openssh-5.8p2-22.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 21 Daniel Walsh 2011-12-12 11:35:37 EST
*** Bug 752197 has been marked as a duplicate of this bug. ***