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.
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 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
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.
If you add full path to restorecon - s/restorecon -F/\/usr\/sbin\/restorecon -F/ - does it work for you?
(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?
And what about 'type -t restorecon' ?