This answer must exist somewhere as it's so basic, but I can't find it.

I have a file on my local computer that I want to copy to a remote host. I know how to use scp, but if I do it from my local host to the remote host, I get a permission error. I can log in to the remote host with root privileges, but I don't know how to identify my local machine (I tried both the internal and external IP addresses and timed out both times). Either method would work for me (although ideally I'd like to know how to do both!)

This is part of an exercise to learn Linux better, so if I'm not presenting the necessary information please let me know what's specifically needed and I'll do my best to elaborate.

(Bonus question: Would love any recommendations for good Linux resources!)

  • Probably a firewall is blocking the incoming ssh connection to your local machine. However, to figure out why your scp command does not work, it would be really helpful to (i) see the command and (ii) the exact error message. – mpy Feb 19 '14 at 19:12
  • 1
    What command are you using for scp, and what user are you logged in as. The problem you are describing might imply you are logging in as a user, then elevating your privs to root - in which case scp does not see the elevated privs. I often get round this problem by copying to /tmp and then moving the file. – davidgo Feb 19 '14 at 19:15
  • Good Linux resources? Try the [linux] tag here on SuperUser ;) – Piskvor Feb 19 '14 at 20:50

This is exactly what rsync was created for! As long as you have SSH access to the remote machine, and the remote machine has rsync installed, then you can:

rsync -avz /path/to/local/file username@host:/destination/path

This will connect over SSH to host as username, launch a private rsync daemon, and then copy the local file to the remote location over the encrypted SSH tunnel. You can also specify a remote location first and a local location second to copy remote files to your local system. If you specify a folder to copy, it will copy the folder and all of it's contents.

Breakdown of the flags:

  • -a "Archive" - copy recursively, and preserve attributes / permissions where possible.
  • -v "Verbose" - Print out each filename after it's copied
  • -z "Compress" - gzip the data as it goes over the network. Faster transfers and lower bandwidth at the cost of CPU processing.

If you're transferring large files, the --progress option might also be useful.

  • Note: this usage requires a rsync server configured and running at host, and provides no encryption (using encryption is highly recommended if connecting over an untrusted network, e.g. the internet). Tunelling through ssh with the option -e ssh removes this requirement (only an installed rsync executable is required, and the connecting client will configure it as necessary); so if you already use ssh access, this allows for transparent SSH authentication+encryption. – Piskvor Feb 19 '14 at 20:46
  • 1
    @Piskvor Rsync does not need to be configured at all on the host, the binary merely needs to be accessible on the $PATH (Note I'm using the : remote notation, not ::, which would require an rsync daemon to be running, and I'm pretty sure that running it in SSH mode (with only a single :) automatically tunnels it over ssh. (Specifying -e ssh isn't necessary to my knowledge, only if you want to use something other than ssh or customize the command) – Darth Android Feb 19 '14 at 21:16
  • This command printed the filename, and then just hung. I let it run for nearly ten minutes (the original file took about a minute to download from the internet) and then I got the message rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at /SourceCache/rsync/rsync-42/rsync/rsync.c(244) [sender=2.6.9] – thumbtackthief Feb 19 '14 at 21:21
  • 1
    @thumbtackthief Try adding the --progress option so that it shows the progress while it transfers and try again. I think it only prints the names after it has successfully copied the file (so you might check that first). Keep in mind that many Internet connections are asymmetrical, so uploading things may take much longer than downloading them. – Darth Android Feb 19 '14 at 21:25
  • @DarthAndroid: I apologize for my ignorance; you are indeed right and I got the : and :: notation confused. – Piskvor Feb 20 '14 at 11:35
ssh username@remotehost tee /home/user/example.file < ./example.local.file

What this does:

  • reads in the contents of local file ./example.local.file
  • SSHs into remotehost as user username
  • launches tee at the remote host
  • and instructs it to put what it gets as input into /home/user/example.file


  • simple


  • overwrites the whole file, regardless of remote file's state
  • which also means the whole file will always be transferred across the wire
  • tee will echo back everything it receives; this may be undesirable with binary files
  • (Note: this is a very rudimentary usage of shell redirection and SSH; @Darth Android's suggestion of rsync is much more robust) – Piskvor Feb 19 '14 at 20:47

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.