SSH is a way to access remote servers via the command line. It is a really fabulous secure communications channel that you can use for all kinds of things! Today, I thought I’d share some of my favorite SSH tips, from starting out, to using multiple SSH keys easily, to using SSH as a tunnel for something else entirely.
To SSH to a remote server, simply take a terminal program (Windows users should grab PuTTY) and type:
ssh username@serverYou’ll be prompted for your password (or passphrase for your key; more on those in a tick), and then — presto! — you’re in. If you don’t supply the username, you’ll be prompted for that first, and the server can take either a domain name like lornajane.net or an IP address.
SSH keys
While it’s fine to use a username and password for SSH access, it’s quicker and more secure to access using an SSH key. SSH keys are made of two parts: a public key and a private key. You generate the keys with the command ssh-keygen (Windows users, download PuTTYGen).
You will be prompted to answer some questions when creating the key, and, in general, the defaults are fine. One of the questions will ask you to create a passphrase. The passphrase is a password that must be used with the key when accessing a server. In general, it is recommended to have passphrases, but you might choose to omit them if, for example, this key will be used by an unsupervised automated user account.
There’s an excellent GitHub resource on generating SSH keys that gives you more information, and it also provides a clue to some of the other things we can do with SSH!
Sharing SSH keys
Once you have your keys, you will need to send the public half (the filename will end with .pub) to anyone who needs to give you access to their server or other app. It is safe to email public keys and to share them, but keep your private keys safe, protected, and backed up. These are the real keys to the kingdom!
GitHub uses SSH keys to grant access to your GitHub account. You paste the contents of your public key into their site (look under “SSH Keys” on your account page), and then you can access your repositories using the key.
Many keys
Some people only have one key, but I find it more helpful to have many keys — perhaps one for work use, and one for personal use, or one created for a specific project or system. This approach means that I can revoke an individual key if I need to, without needing to change all of my keys.
To SSH with a specific key is very simple. You can supply the information on which key to use with the -i switch to the ssh command. For example, I have a separate SSH key to use with GitHub:
ssh -i ~/.ssh./github_rsa git@github.comUsing multiple keys in this way is great for accessing servers, but many of the programs which rely on SSH, such as scp and git don’t have an option to specify which key to use. For this situation (and many others), you can use the SSH config file.
SSH configuration file
The config file for SSH is the source of many very useful little tricks! (On Unix systems, it lives in ~/.ssh/config.) For example, you might set up an alias so that you can refer to a server by a shorter name:
Host lyra
User=lorna
Hostname=lyra.lornajane.netNow, I can simply SSH to the alias, and it will pick up the hostname and username accordingly:
$ ssh lyra
lorna@lyra.lornajane.net's password:Using the config file, you can also tell SSH which key to use when accessing a different server. Here’s the entry I use for accessing GitHub:
Host GitHub
Hostname=github.com
IdentityFile=~/.ssh/github_rsaThis does mean that I edit all the URLs I use to be GitHub, where normally there would be github.com. It reminds me that there’s some magic somewhere!
SSH tunnels
Earlier, I mentioned that it’s possible to use SSH connections as a transport for other protocols. I use this mostly to get around the issue that some clients’ tools are locked down to my home static IP address. There’s a server in the house that does a bunch of handy things, but also accepts SSH connections, so I can tunnel through it to make my traffic look like it came from there.
To achieve this, I use the -L switch to bind a specific port on my local machine (such as 8080) to a specfic port on the server that I actually want to access. This will only work if the connection is made through my static IP address, so the house becomes the target of the SSH command. It looks something like this:
ssh -L 8080:client-tool.example.com:80 home-server.lornajane.netI am prompted for my SSH credentials for home-server.lornajane.net, and the connection is created. Anything I send to 8080 on my local machine will be forwarded over an SSH tunnel via the house to port 80 at client-tool.example.com. So, I open http://localhost:8080/, and by SSH magic, I have access to the client tool that’s only available from the whitelisted IP address!
This is an invaluable trick and one that I use when I’m on the road most of all. It can be used to send all kinds of traffic, not just HTTP. I’ve used it for rsync, telnet, other file transfers, and who knows what else. I’ve also used it to route my web traffic through a proxy as a way of working around restrictive firewalls.
The power of SSH
SSH is such a key skill in working with remote commands, but it’s one of those awkward things that isn’t usually taught; you don’t learn SSH when you perfect your technical craft, yet you need it to be able to share what you create. Hopefully this post has given you a useful snippet or two to make sharing a little bit easier.
