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
Is it possible to transfer this file via
ssh to the remote computer?
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
~/Downloads to remote computer, use:
scp ~/Downloads/yourfile.txt email@example.com:/some/remote/directory
You can see more examples here.
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
tar the current directory on the local machine, and write that
stdout which will then be piped to an
ssh command where it will execute a remote command to untar the file it reads from
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.
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 firstname.lastname@example.org:/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 ~/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
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.
First time, there is no real difference between
scp (copy over
Subsequent runs will benefit by rsync not copying files that already exist.
rsync -avH ~/Downloads username@remotehost:Downloads
-afor all files
-Hfor "just figure out symlinks and do the right thing"
Other useful flags include:
--deleteto delete files in the destination that no-longer exist on the source.
--dry-runfor testing - very handy when combined with
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.
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.
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.