Always Remember: With Gusto Comes Data Loss.

SSH and SCP Guide

SSH

This guide is going to provide an overview of how to use SSH and SCP to connect to remote computers, run commands, and transfer files to and from them. ssh allows you to have command-line access to other computers over a relatively secure connection. scp lets you copy files to and from another computer over that same secure connection. If you type just ‘ssh’ into the CL you get one of the more obtuse usage messages that I’ve seen:

usage: ssh [-1246AaCfgKkMNnqsTtVvXxYy] [-b bind_address] [-c cipher_spec]
       [-D [bind_address:]port] [-e escape_char] [-F configfile]
       [-I pkcs11] [-i identity_file]
       [-L [bind_address:]port:host:hostport]
       [-l login_name] [-m mac_spec] [-O ctl_cmd] [-o option] [-p port]
       [-R [bind_address:]port:host:hostport] [-S ctl_path]
       [-W host:port] [-w local_tun[:remote_tun]]
       [user@]hostname [command]

Huh? Before we get too much further lets define our computer setup. We have a notebook we’re typing at (a Macbook Air, for example) and we are ssh’ing into a server (a Mac Mini).

The Macbook Air’s details:

  Computer Name: mba
  Username: josh
  IP Address: DHCP, on the same local network as the server

The Mac Mini Server’s details:

  Computer Name: server
  Username: admin
  IP Address: static @ 10.0.1.60

1) Getting yourself logged in

It’s important to note that the usernames for the two computers are different since that’s the first gotcha most people run into when getting started. ssh will ask for a password for the remote computer, but will not ever prompt you for a user name. If not told otherwise ssh will assume the user name on the remote machine will be identical to the user name on the local computer. So typing something like this:

$ ssh 10.0.1.60

will never be able to connect because there is no user named ‘josh’ on the server. How do you specify a user? There are two different ways: Prepend the user name before the servername (user@server) or use the -l switch. Personally I prefer using the @ because it is one less switch that needs to be passed if you choose to pipe the command (which means less chance of something weird happening). Both commands below have the same effect of choosing the admin user.

$ ssh amdin@10.0.1.60
$ ssh 10.0.1.60 -l admin

which gives you the successful login message:

Last login: Wed Mar  20 11:51:10 2013
server:~ admin$

If you are working in a bonjour-enabled environment, you could also have typed

$ ssh admin@server.local

and that would have gotten you in just the same, but without having to remember the IP address. An IPv4 address isn’t all that hard, but when things go full IPv6 remembering and typing out specific addresses will be tedious.

 

An interesting little trick is that you can also add commands at the end of a ssh login request if you know exactly what you want to do and don’t need any feedback (creating a folder, running a script, starting a permissions repair, etc.). This is done like so:

$ ssh admin@10.0.1.60 mkdir NEW_FOLDER

This will create a new folder on the remote server in the admin’s home folder.

SCP

scp allows you to copy files and folders to and from a remote computer. It uses the same login and data encryption methods as ssh, and therefore just as secure. You can adjust the encryption method manually if you prefer to trade security for speed.

Basic Syntax:

scp [source file] [destination]

Some notes on the following syntax that are universal to terminal:

~  ==  Start the path at your home folder. ~/Desktop references the specified user's desktop
.  ==  . (dot or period) means 'here' as in "copy the file right here, in the folder where I'm at now"

When referencing a remote file you use the same username@server syntax, but append the path to your file separated by a colon. This will copy the local file ‘foo.bar’ from our current working directory to the Desktop of our remote server: 

$ scp foo.bar admin@10.0.1.60:~/Desktop/
$ scp foo.bar admin@server.local:~/Desktop/

Note: Both lines have the same outcome, just using a different method to name the remote computer

This will copy the specified file from the remote server to your local computer (note the “.” at the end, indicating it should copy the file to our current working directory):

$ scp admin@10.0.1.60:~/foo.bar .

scp -r will copy whole folders recursively:

$ scp -r Camera/ admin@10.0.1.60:~/

scp -p will preserve file time stamps while copying. This may not matter to most people, but useful if you don’t want all of your files looking like they were created a few minutes apart from eachother. The -r and -p switches can be combined to say

$ scp -rp Camera/ admin@10.0.1.60:~/

For large files or when copying many files/folders recursively scp will display a progress bar:

Biggish_File.dmg              2%   96MB  11.9MB/s   05:30 ETA

If you are transferring a very large file, and are not terribly concerned about security, you can lower the level of encryption, which can speed up scp significantly. Through some research and my own testing, I have found that the ARC4 (or arcfour) cipher is the fastest way to transfer using scp:

$ scp -c arcfour Big_File admin@10.0.1.60:~/

One other trick is to use /dev/null as a destination if you want to test transfer speeds without filling up the destination drive. This allows you to send multiple gigabyte files without actually storing anything on the remote end. The syntax for this would look like:

$ scp -c arcfour Test_File admin@10.0.1.60:/dev/null

After trying all those examples you are probably sick of typing in your password over and over and over and over again. Now on to Part 3!

Using PKI

Insert the obligatory ‘be careful when using saved passwords’ warning here. If bad people get access to your computer very bad things could happen. Ok. Warning received. Moving on.

If you are logging in to a remote machine frequently, or want to add ssh functionality into an automated script you can register your two computers together by sending their keys back and forth which does the automatic authentication without the prompt for typing in a password. In an extremely abbreviated explanation keys work in pairs, one public you share with the world, one private you keep well protected. On you own local machine (not ssh’ed in elsewhere) in your terminal window type:

$ ssh-keygen

Press enter a few times until you get something like this:

Generating public/private rsa key pair.
Enter file in which to save the key (/Users/josh/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/josh/.ssh/id_rsa.
Your public key has been saved in /Users/josh/.ssh/id_rsa.pub.
The key fingerprint is:
61:FA:KE:HE:XA:DE:CI:MA:LS:65 josh@mba.local
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|    pretty       |
|      ascii      |
|                 |
|  art            |
|      goes       |
|                 |
|         here    |
|                 |
+-----------------+

now do a ls -l .ssh/

$ ls -l .ssh/
   -rw-------  1 josh  staff  1675 Mar 20 12:05 id_rsa            <--- priavte
   -rw-r--r--  1 josh  staff   403 Mar 20 12:05 id_rsa.pub        <--- public
   -rw-r--r--  1 josh  staff   782 Mar 20 09:24 known_hosts       <--- list of previous connections

id_rsa is the file you don’t want ending up in other’s hands. id_rsa.pub is the public file that you’re going to copy to the server you want to have password-less connections to. There is a third file ~/.ssh/authorized_keys2 that ssh stores your public key in. You can have multiple public keys saved in that one ~/.ssh/authorized_keys2 file, if you want to have multiple computers have auto-login access. Now, we could use Finder, filesharing & Textedit to copy our public key over, but we’re better than that!

$ cat .ssh/id_rsa.pub | ssh admin@10.0.1.60 'cat >> .ssh/authorized_keys2'

cat outputs the contents of a file to standard output (your screen displays standard output). The output of id_rsa.pub is captured by the pipe (|) which routes the output to ssh admin@ 10.0.1.60. We add a command at the end of our ssh login request  ‘cat >> .ssh/authorized_keys2’  where the >> means save the output of cat .ssh/id_rsa.pub into this file .ssh/authorized_keys2 and if it exists already, add the new text to the end of the file. A single > would overwrite the whole file clean.

Now try logging in again and huzzah! No password prompt!

 

Bonus Level!

Now that we have covered basic file movements with scp and passwordless logins with ssh, there is one more trick up scp’s sleeve: coping from one remote computer to another. There are two ways to make this happen: Directly, and with your computer as a go-between. If you want the two remote computers to communicate directly you first have to setup passwordless logins between the two. Once that is done:

$ scp admin@10.0.1.50:~/foo.bar admin@10.0.1.60:~/

If you aren’t able or don’t want to setup automatic logins, the -3 option will transfer from remote1 -> local -> remote3 (-3 is odd notation for switches – they are not typically numerals. scp actually has a few numeral switches. weird.)

$ scp -3 admin@10.0.1.50:~/foo.bar admin@10.0.1.60:~/

And there you have it. You are now a master of SSH and SCP. Go forth and prosper!

3 thoughts on “SSH and SCP Guide

  1. so … a few things…

    first of all the ssh usage is pretty damn straight forward, tells you the options, as with all things coming out of the OpenBSD project the manual pages are very well written and well worth the time reading. If you’re used to other man pages (most things GNU … shudder) I can understand you reluctance, but here they’re a really good. Further reading the error logs from ssh will solve 95% of your issues, the rest will be solved by tossing on -v (or -vv or -vvv) to your commands.

    second, are you examples from an older box? These days ecdsa is generally preferred over rsa, faster and I believe slightly more secure.

    third, as of several versions ago, authorized_keys2 is depreciated, you should just be using authorized_keys, this will break stuff on newer versions of OpenSSH

    fourth as a bonus you should give an example on setting up proxying through corporate firewalls with ssh, always a skill you want don’t want the corporate overlords knowing what you’re surfing ;-)

    • It’s true – the man page for SSH is actually pretty good. This was originally put together for my co-workers who were almost entirely Windows based and only had to touch SSH on occasion. They would look at the man page and I could see their eyes glaze over. This post is pretty much intended for beginners or those who just need a quick syntax reference/example.

      Yes, this was originally written back in 2009. I keep a folder of a bunch of my old write-ups just in case I ever need them in the future. This blog seemed like a nice dumping ground for much of those. You are right that ecdsa is the preferred algorithm these days, though it may cause problems with systems running older versions of SSH. Now that I think about it though, most of those systems will be falling out of service relatively soon, so I may update that section when I get a moment.

      You are right again about keys2 vs keys. It looks like this document is dating itself. I’ll have to correct that soon.

      As for the ssh tunnel tutorial, I actually have that write-up saved as a draft right now. I’ll likely finish it up by the end of the month.

      • ah, then this all makes sense. yeah I actually had to check if apple has updated sshd to a more recent version as many vendors update it far to seldom, but yes it does have ecdsa support, but yeah I think the default for systems is to make one of each (dsa, rsa and ecdsa) for personal use I think the two latter would suffice in most places, but most things these days should support ecdsa.

        Other than that good basics on ssh, it’s one of the best programs to know a lot about, and I just know enough to get me through my day.

Leave a comment

Your email address will not be published. Required fields are marked *