17

I have a series of software files downloaded into my subdirectory ~/Downloads on my personal computer. I am also using bash to connect remotely to a computer using ssh.

Is it possible to transfer this file via ssh to the remote computer?

  • The question refers to a singular file (this file) and multiple files (a series of software files), the best solution depends upon whether you have a single file or multiple files. – user2768 Nov 11 '15 at 9:39
42

You may want to use scp for this purpose. It is a secure means to transfer files using the SSH protocol.

For example, to copy a file named yourfile.txt from ~/Downloads to remote computer, use:

scp ~/Downloads/yourfile.txt your_username@remotehost.edu:/some/remote/directory

You can see more examples here.

  • 5
    I think rsync may work as well, now that I think about it – ShanZhengYang Nov 10 '15 at 16:32
  • 1
    rsync is far to complex for just one or a hand full of files... – Paebbels Nov 10 '15 at 20:13
  • 14
    @Paebbels On the contrary, replace scp above with rsync and it should work just fine. – 8bittree Nov 10 '15 at 21:23
  • I tend to use rsync for everything, even single files, because it "just works" in the simple cases and can be far more efficient in other cases. If using either scp or rsync on anything not already compressed and/or encrypted, remember to turn the compression option on (-C for scp, -z or --compress for rsync). In fact I turn it on by habit - it is very rare you'll find a circumstance where it ever slows things down (perhaps if you are using a slow low-power device with limited CPI power like an rPi). – David Spillett Nov 12 '15 at 17:04
38

Though scp is clearly the right tool for this, if for some reason you can't use it you could do something like the following from your local machine to copy, say, a directory structure to the remote machine:

tar -c . | ssh <remote> tar -x

This will tar the current directory on the local machine, and write that tar to stdout which will then be piped to an ssh command where it will execute a remote command to untar the file it reads from stdin

Edited to reflect Dietrich Epp's comment about -f - being the default on both the creation and extraction ends, so not being necessary to specify explicitly.

  • 7
    You'll probably want to add a -C basedir argument to tar to extract somewhere other than your home directory if you're doing this. – Dougal Nov 11 '15 at 8:29
17

If you want to do this on more than the rare occasion, I'd suggest mounting the remote filesystem with sshfs if you are using a Unix-like that supports FUSE (Linux, *BSD, Mac OS X). Make a directory under your home directory, say, called ~/remote-server:

    $ mkdir ~/remote-server

Then mount the remote filesystem with sshfs. Replace "yourserver.com" with the host name of your remote machine, and "name of remote directory" with the directory you are using on the remote system.

    $ sudo sshfs username@yourserver.com:/name/of/remote/directory ~/remote-server/

Once this is done, the remote directory is part of your filesystem and you can use all your normal tools on it, including cp:

    $ cp ~/Downloads/your-files ~/remote-server

If you don't already have sshfs installed, you should be able to install it on your computer using your package manager (look for packages named sshfs or fuse-sshfs). For more information, you can read a tutorial online.

This, by the way, is my favorite way of managing files on remote servers. I normally keep one production server and two development servers mounted in this way and use my normal file browsing workflow with them.

  • And then check which sshfs options will help you get your work best done. E.g. starting with user/group ID mapping -o idmap={none,user,file},gid=<remote_user_group_ID>,allow_other and -C for compression if poor bandwith. As soon as it works good, I personally add aliases for the commands to quickly mount the distant filesystems over ssh. @Benjamin_Staton I wouldn't use sudo or root here, not without a proper user/group mapping at least. – tuk0z Nov 10 '15 at 22:36
9

First time, there is no real difference between scp (copy over ssh) and rsync.

Subsequent runs will benefit by rsync not copying files that already exist.

rsync -avH ~/Downloads  username@remotehost:Downloads
  • -a for all files
  • -v for verbose
  • -H for "just figure out symlinks and do the right thing"
  • then source and destination paths. You can use wildcards in the source, or just sync the whole directory.

Other useful flags include:

  • --delete to delete files in the destination that no-longer exist on the source.
  • --dry-run for testing - very handy when combined with --delete.

This will use ssh keys to do a passwordless login too, if you have them set up.

At the end of the run, rsync will tell you how many times faster it was over doing the plain copy over again.

  • 1
    -H is actually for hard links, it stops the same content being sent twice or more when it is linked into more than one place in the source directory structure (but can make the process less efficient for large directory structures). it has no effect on symbolic links, but some of the options included by -a/--archive do affect how symlinks are processed. – David Spillett Nov 12 '15 at 17:08
4

To add to above answers. Sometimes I am not exactly sure about remote path. In these cases I use sftp to first navigate to required location, then use get or put to actually download or upload a file.

If you also want to keep something always synced and even want to execute locally some file that is located on remote machine, sshfs works great.

-1

I'm doing something very similar with ssh. I created a custom build tool for Visual Studio and am basically having VS run an ssh command that copies my code to a target computer and then compiles it on that target computer.

ssh userB@hostB 'cp /network/path/of/source/file.ext /path/of/final/file.ext; ./runCustomCommand'

Notice the use of single quote mark and semi-colon. The former encapsulates your commands to hostB via ssh and the latter allows you to run multiple hostB system commands in one ssh command from hostA.

In order to make this work, you'll need to set up ssh keys on your start machine so that you can be userA@hostA and login to hostB as userB. The process for creating a public ssh key for userA@hostA is well documented. If you don't create a public key on hostA for userA, and copy that key to hostB as userB, then you'll be forced to enter your password every time - which ruins the joy of automation.

  • Can anyone who downvoted leave a comment as to why they downvoted? Down votes are meaningless without informative feedback.Thanks. I have addressed the OP's specific question with an answer that directly relates. I'm not introducing new technology or suggesting alternate routes. Why? maybe OP doesn't want to use alternate routes. – Andrew Nov 23 '15 at 18:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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