This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 994542 - ssh-copy-id does not succeed in setting selinux labels for .ssh and .ssh/authorized_keys
ssh-copy-id does not succeed in setting selinux labels for .ssh and .ssh/auth...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
19
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Petr Lautrbach
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-07 09:28 EDT by Mark Lamourine
Modified: 2017-07-18 08:01 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-14 11:21:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark Lamourine 2013-08-07 09:28:12 EDT
Description of problem:

ssh-copy-id fails to set correct SELinux labels on ~/.ssh and ~/.ssh/authorized_keys


Version-Release number of selected component (if applicable): 
  openssh-clients-6.2p2-5.fc19.x86_64


How reproducible:

use 'ssh-copy-id' to create .ssh and .ssh/authorized_keys files on an account
where they do not exist.


Steps to Reproduce:
1. on target account: rm -rf ~/.ssh
2. on source account: ssh-copy-id -i <id file> targetuser@targethost
3. on source account: ssh -i <id file> targetuser@targethost



Actual results:

$ ssh -i <id file> mlamouri@oo-ident-f19
mlamouri@oo-ident-f19's password: 

[mlamouri@oo-ident-f19 ~]$ restorecon -vr ~/.ssh
restorecon reset /home/bos/mlamouri/.ssh context unconfined_u:object_r:home_root_t:s0->unconfined_u:object_r:user_home_t:s0
restorecon reset /home/bos/mlamouri/.ssh/authorized_keys context unconfined_u:object_r:home_root_t:s0->unconfined_u:object_r:user_home_t:s0


Expected results:
$ ssh -i <id file> targetuser@targethost
[mlamouri@oo-ident-f19 ~]$


Additional info:

/usr/bin/ssh-copy-id line 275 does indicate that it will force set the context for ~/.ssh and ~/.ssh/authorized_keys:

---- lines 272:276
    [ "$DRY_RUN" ] || printf '%s\n' "$NEW_IDS" | ssh "$@" "
		umask 077 ;
		mkdir -p .ssh && cat >> .ssh/authorized_keys || exit 1 ;
		if type restorecon >/dev/null 2>&1 ; then restorecon -F .ssh .ssh/authorized_keys ; fi" \
      || exit 1

----

Also manually running the restorecon -F on the target host results in proper labeling.
Comment 1 Mark Lamourine 2013-08-07 09:34:46 EDT
I removed the shell output redirects from the 'type restorecon' fragment of the remote ssh script and got this:

-------------
[mlamouri@mlamouri ~]$ sh ./ssh-copy-id -i ~/.ssh/markllama@redhat.com_rsa oo-ident-f19
./ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
./ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
mlamouri@oo-ident-f19's password: 
bash: line 3: type: restorecon: not found

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'oo-ident-f19'"
and check to make sure that only the key(s) you wanted were added.
--------------

Logging in normally restorecon is in the default path:

mlamouri@oo-ident-f19's password: 
Last login: Wed Aug  7 13:23:09 2013 from dhcp-33-1.bos.redhat.com
[mlamouri@oo-ident-f19 ~]$ which restorecon
/usr/sbin/restorecon

[mlamouri@oo-ident-f19 ~]$ restorecon -Fv .ssh .ssh/authorized_keys 
restorecon reset /home/bos/mlamouri/.ssh context unconfined_u:object_r:home_root_t:s0->unconfined_u:object_r:user_home_t:s0
restorecon reset /home/bos/mlamouri/.ssh/authorized_keys context unconfined_u:object_r:home_root_t:s0->unconfined_u:object_r:user_home_t:s0
Comment 2 Mark Lamourine 2013-08-07 09:38:05 EDT
Adding "echo $PATH" to that fragment gives:

/home/bos/mlamouri/bin:/usr/lib64/qt-3.3/bin:/usr/libexec/lightdm:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin
bash: line 4: type: restorecon: not found

Since /usr/bin is in the path, I'm not sure why /usr/bin/restorecon is not being found.
Comment 3 Petr Lautrbach 2013-08-08 05:05:35 EDT
If you add full path to restorecon - s/restorecon -F/\/usr\/sbin\/restorecon -F/ - does it work for you?
Comment 4 Petr Lautrbach 2013-08-08 05:24:12 EDT
(In reply to Petr Lautrbach from comment #3)
> If you add full path to restorecon - s/restorecon -F/\/usr\/sbin\/restorecon
> -F/ - does it work for you?

O, that was based on wrong reading. Forget about it.

The issue is that 'type restorecon' can't interpret restorecon. I don't know why.

> mlamouri@oo-ident-f19's password: 
> bash: line 3: type: restorecon: not found
>
> [mlamouri@oo-ident-f19 ~]$ which restorecon
> /usr/sbin/restorecon

Have you tried also 'type restorecon' in a running shell on the remote machine?
Comment 5 Petr Lautrbach 2013-08-08 05:27:00 EDT
And what about 'type -t restorecon' ?

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