1

How to copy a folder from remote using remote user with sudo? None of these works on folders with permissions and fails with permission denied:

scp -r [email protected]:/source/ /destination/
sudo scp -r [email protected]:/source/ /destination/

When I ssh on remote and perform sudo su then I can view those files and folders. For me it doesn't matter to use scp or smth else as long as it's ssh based.

Maybe it's a limitation of scp to use sudo rights as security benefit. However it's really frustrating to be able to ssh, perform sudo su and view all the folders, however not be able to download from remote (though you can probably workaround that with tar and download anyway)

4
  • 3
    ssh to the remote host, then there, doing a sudo scp back to where you are isn't an option?
    – infixed
    Mar 25, 2016 at 10:58
  • Maybe related to superuser.com/questions/138893/scp-to-remote-server-with-sudo?
    – phk
    Mar 25, 2016 at 11:00
  • same concept, but that question on superuser has an accepted answer that Centurion is trying to avoid. Though the 3rd answer (rsync with --rsync-path) is pretty good.
    – M Conrad
    Mar 25, 2016 at 21:20
  • Running sudo on your local machine does not give you root access on a remote machine. your 2nd command sudo scp ... runs the local scp command as root, but the args tell it to connect as userwithsudo on the remote machine. That user may have sudo privs to some or all commands but only when they actually run sudo....and scp has no way of doing that. The only way i can think of to do what you want is with rsync's --rsync-path=PROGRAM option to run sudo rsync (perhaps with a wrapper script) as the remote rsync program.
    – cas
    Mar 25, 2016 at 22:43

3 Answers 3

3

Assuming you have or can give yourself NOPASSWD access (either to all commands, or just 'tar' or 'cat') it can be as simple as

# For a single file
ssh [email protected] 'sudo cat /source/SINGLE_FILE' > /destination/SINGLE_FILE

# for recursive copying, use tar or cpio
ssh [email protected] 'sudo tar -C /source/ -czf - .' | tar -C /destination/ -xzf -

You have to run sudo on the remote side, and then pipe the files through a program that writes stdout to a program that reads stdin.

If you need to be able to enter your password for sudo things get a lot uglier, but it can be done with rsync servers and port forwards.

6
  • This won't work unless the user is allowed to sudo with NOPASSWD. Mar 25, 2016 at 21:30
  • If they have un-restricted sudo access they can give themself this ability. But true, i should mention it in the answer
    – M Conrad
    Mar 25, 2016 at 21:49
  • How can you this backwards? I mean the origin file is in my system and the remote part is destination
    – X3MBoy
    Aug 26, 2020 at 17:18
  • 1
    @X3MBoy cat /path/to/local/SINGLE_FILE | ssh [email protected] 'sudo tee /destination/SINGLE_FILE >/dev/null' for a file or tar -C /local/source/ -czf - . | ssh [email protected] 'sudo tar -C /destination/ -xzf -' for a directory. (using tee for a single file because a shell redirection would happen outside the sudo, unless you use a more complicated /bin/sh -c combination)
    – M Conrad
    Aug 28, 2020 at 3:15
  • @MConrad Thanks! This works
    – X3MBoy
    Sep 9, 2020 at 23:18
1

Ensure which user has to use sudo - local or remote (or both) users? i.e. sudo scp affects only local user rights to performing scp command.

As a solution - try to move source files under another directory with remote user ownership and rights and check write permissions for the local user in place where destination folder should be created.

Also try to move source to the remote user home directory - i.e. what path is in ~ (it could be a result of the server security policy).

0

The file you try to get should have modified permission on it (own by root or non readable permission on this specific files & folders) So the simplest way to get that file is to scp to the root not the user.

scp -r [email protected]:/source /destination/

Enable root login over SSH (From RedHat)

Security point of view, that is better to no allow that sort of things, but if you need to do that, you should use a key and had it to the /root/.ssh/authorized_keys

Not the answer you're looking for? Browse other questions tagged .