SSH is a life-saver when you need to remotely manage a computer, but did you know you can also upload and download files, too? Using SSH keys, you can skip having to enter passwords and use this for scripts!
This process works on Linux and Mac OS, provided that they’re properly configured for SSH access. If you’re using Windows, you can use Cygwin to get Linux-like functionality, and with a little tweaking, SSH will run as well.
Copying Files Over SSH
Secure copy is a really useful command, and it’s really easy to use. The basic format of the command is as follows:
scp [options] original_file destination_file
The biggest kicker is how to format the remote part. When you address a remote file, you need to do it in the following manner:
The server can be a URL or an IP address. This is followed by a colon, then the path to the file or folder in question. Let’s look at an example.
scp –P 40050 Desktop/url.txt firstname.lastname@example.org:~/Desktop/url.txt
This command features the [-P] flag (note that it’s a capital P). This allows me to specify a port number instead of the default 22. This is necessary for me because of the way I’ve configured my system.
Next, my original file is “url.txt” which is inside of a directory called “Desktop”. The destination file is in “~/Desktop/url.txt” which is the same as “/user/yatri/Desktop/url.txt”. This command is being run by the user “yatri” on the remote computer “192.168.1.50”.
What If you need to do the opposite? You can copy files from a remote server similarly.
Here, I’ve copied a file from the remote computer’s “~/Desktop/” folder to my computer’s “Desktop” folder.
To copy whole directories, you’ll need to use the [-r] flag (note that it’s a lowercase r).
You can also combine flags. Instead of
scp –P –r …
You can just do
scp –Pr …
The toughest part here is that tab completion doesn’t always work, so it’s helpful to have another terminal with an SSH session running so that you know where to put things.
SSH and SCP Without Passwords
Secure copy is great. You can put it in scripts and have it do backups to remote computers. The problem is, that you may not always be around to enter the password. And, let’s be honest, it’s a real big pain to put in your password to a remote computer you obviously have access to all the time.
Well, we can get around using passwords by using key files. We can have the computer generate two key files – one public that belongs on the remote server, and one private which is on your computer and needs to be secure – and these will be used instead of a password. Pretty convenient, right?
On your computer, enter the following command:
ssh-keygen –t rsa
This will generate the two keys and put them in:
with the names “id_rsa” for your private key, and “id_rsa.pub” for your public key.
After entering the command, you’ll be asked where to save the key. You can hit Enter to use the above-mentioned defaults.
Next, you’ll be asked to enter a passphrase. Hit Enter to leave this blank, then do it again when it asks for confirmation. The next step is to copy the public key file to your remote computer. You can use scp to do this:
The destination for your public key is on the remote server, in the following file:
Subsequent public keys can be appended to this file, much like the ~/.ssh/known_hosts file. This means that if you wanted to add another public key for your account on this server, you would copy the contents of the second id_rsa.pub file into a new line on the existing authorized_keys2 file.
Isn’t this less secure than a password?
In a practical sense, not really. The private key that’s generated is stored on the computer you’re using, and it is never transferred, not even to be verified. This private key ONLY matches with that ONE public key, and the connection needs to be started from the computer that has the private key. RSA is pretty secure and uses a 2048 bit-length by default.
It’s actually pretty similar in theory to using your password. If someone has knows your password, your security goes out of the window. If someone has your private key file, then security is lost to any computer that has the matching pubic key, but they need access to your computer to get it.
Can this be more secure?
You can combine a password with key files. Follow the steps above, but enter a strong passphrase. Now, when you connect over SSH or use SCP, you’ll need the proper private key file as well as the proper passphrase.
Once you enter your passphrase once, you won’t be asked again for it until you close your session. That means that the first time you SSH/SCP, you’ll need to enter your password, but all subsequent actions won’t require it. Once you log out of your computer (not the remote one) or close your terminal window, then you’ll have to enter it again. In this way, you’re not really sacrificing security, but you’re also not harassed for passwords all the time.
Can I reuse the public/private key pair?
This is a really bad idea. If someone finds your password, and you use the same password for all of your accounts, then they now have access to all of those accounts. Similarly, your private key file is also super-secret and important. (For more information, take a look at How To Recover After Your Email Password Is Compromised)
It’s best to create new key pairs for every computer and account you want to link. That way, if one of your private keys get caught somehow, then you’ll only compromise one account on one remote computer.
It’s also really important to note that all of your private keys are stored in the same place: in ~/.ssh/ on your computer, you can use TrueCrypt to create a secure, encrypted container, then create symlinks in your ~/.ssh/ directory. Depending on what I’m doing, I use this super-paranoid super-secure method to put my mind at ease.
Have you used SCP in any scripts? Do you use key files instead of passwords? Share your own expertise with other readers in the comments!
Yatri Trivedi is a monk-like geek. When he's not overdosing on meditation and geek news of all kinds, he's hacking and tweaking something, often while mumbling in 4 or 5 other languages.
- Published 06/24/11