Bugzilla – Bug 597
Executing scp in batch mode fails when run with sudo, succeeds with su.
Last modified: 2013-08-17 15:09:59 MDT
Here's the situation. I have 2 virtual machines running Fedora. Let's call them Able and Baker. I have a user, let's call it bob, on each VM. I have set up passwordless authentication to allow bob to ssh or scp from Able to Baker. I have a script that runs scp in batch mode (it runs at Able and copies a file from Baker). When I run (as bob) [bob@Able ~]$ /home/bob/scpScript it works. When I su to root, and run [root@Able bob]$ /home/bob/scpScript it works. When I run (as bob again) [bob@Able ~]$ sudo -u bob /home/bob/scpScript it works. BUT when I run bob@Able ~>sudo /home/bob/scpScript I get: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). That is, a permission denied error from scp. This is unexpected. Is this expected behavior?
Can you add the -v flag to your scp and add the extra info you get? When you say "passwordless authentication" I'm assuming you mean you are using a key that is not encrypted with a passphrase. Is that correct?
Created attachment 364 [details] Verbose run of scp with sudo This is scp run with the -v flag using sudo
Created attachment 365 [details] Verbose run of scp using su to elevate permissions This is scp run in verbose mode after gaining root credentials using su
I've attached output of running scp in verbose mode with sudo, and, for comparison, running the same thing after gaining root permissions with su. When I say passwordless authentication, I mean the authentication method scp calls "publickey", where I generate an ssh key pair, and copy the public part to the remote machine's list of authorized keys. The key is not password protected. Only the bob user has an authorized key on the remote host. When run with sudo, scp attempts to use a key belonging to root. When I get root credentials with su, it uses bob's key.
Created attachment 366 [details] Verbose run of scp using so to elevate permissions This is scp run in verbose mode after using su to gain root credentials.
When you run sudo scp, scp will look for the public key in root's home directory since the LOGNAME and USER environment variables are set to the target user (root in this case). If you explicitly specify the identity file to use with scp's -i flag it should work. Alternately, if you are using the ssh agent you could add SSH_AUTH_SOCK to the env_keep list in sudoers. E.g. Defaults env_keep += "SSH_AUTH_SOCK"
The reason it works with su is that su does not change the environment by default (unless you use the -l flag). If you specify the path to the identity to use it will work. The SUDO_USER environment variable is set by sudo to the name of the invoking user, so you can use that to help find the invoking user's .ssh directory.