My love story with SSH

Whether you are a web developer or a system administrator, there's no reason to not master the tools of the SSH ecosystem. I don't mean calculating public keys in your head: just to know SSH from the user point of view.

As a disclaimer before starting, all my examples are based on Unix machines (Linux in particular).

SSH as a powerful telnet

The first use case that comes to mind when talking about SSH is included in its name: Secure SHell. You can easily login remotely on a machine running sshd (on Debian derivates it's installed with the package openssh-server), using the credential of your account in that machine. It's like actually being there, in a terminal, minus some latency if you type very fast.

The command to type for opening a shell on the remote machine is simply:

ssh user@192.168.0.2

Substitute 192.168.0.2 with your target ip address. Note that is user is the same on local and remote machines (and typically it is), you can omit it and just type

ssh 192.168.0.2

Protocols over ssh

Having an already existent communication channel is so handy that many other protocols fit into ssh nicely, leveraging its authentication mechanism. For example, rsync can work over ssh for synchronizing files between multiple machines. More famous examples are git's remotes definitions: you can git clone and git push via an ssh connection.

Note: sshd listens on the 22 port, so remember to check port-forwarding for out-of-LAN communication.

Forget your password

It's a pity having to type your password every time you want to connect to another machine. So you can easy set up authentication via a public/private key pair. I won't enter into the detail of how asymmetric crypthography works, but the point is you generate a private key on the computer you want to connect from, and a corresponding public key that can be distributed to the target machines. If the client is compromise, the public key will be invalidated. The server cannot compromise your private key instead, as it have only the public one.

Generate a (RSA by default) pairs of keys via:

ssh-keygen

Then copy the public key, usually ~/.ssh/id_rsa.pub, in the host where you want to connect. Add it to .ssh/authorized_keys (it's a single line). After this session, you'll never need to type your password again.

By the way, you can also launch the ssh-copy-id utility that handles this process for you.

As a side note, I enter no passphrase when generating my keys. ssh-agent and keychain are a whole new can of worms, and even if they're able to keep in memory your decrypted key, it's much more convenient to just skip the passphrase step when working in a LAN.

Name your machines

You can add LAN (and remote) addresses as new lines in /etc/hosts (you need to be root).
The format is:

192.168.0.2 Desmond

Desmond is an example: I name my boxes like movie and TV series characters.

Now you can type in your local terminal:

ssh Desmond

If you want to make your machines available out of your NAT, remember to configure port forwarding on the router like you would do for any database or web server; the ip to cite in external machines is the router's public one.

Color your prompts

I don't remember when, by I added this to my .bashrc file, which is synchronized across machines:

C_RED="\[\033[0;31m\]"
C_GREEN="\[\033[0;32m\]"
C_LIGHT_GRAY="\[\033[0;37m\]"
C_RESET="\[\033[0m\]"
C_BROWN="\[\033[0;33m\]"
C_BLUE="\[\033[0;34m\]"
C_PURPLE="\[\033[0;35m\]"
C_CYAN="\[\033[0;36m\] "
C_GRAY="\[\033[1;30m\]"
C_WHITE="\[\033[1;37m\]"
C_YELLOW="\[\033[1;33m\]"
C_LIGHT_BLUE="\[\033[1;34m\]"
C_LIGHT_CYAN="\[\033[1;36m\]"
C_LIGHT_PURPLE="\[\033[1;35m\]"
C_LIGHT_RED="\[\033[1;31m\]"
C_LIGHT_GREEN="\[\033[1;32m\]"
source ~/.bash_prompt

Then I created a .bash_prompt file in each of the home directories in the various machines I need to work on.

PS1="$C_GRAY[$C_LIGHT_BLUE\t$C_GRAY][$C_LIGHT_BLUE\u@\h:\w$C_GRAY]\$ $C_RESET"

The colors I chose are different for each machine: for example: red, green and blue. It's handy to notice you are on the wrong machine, particularly if you have more than one terminal open (one is of the wrong color).

However the hostname is already displayed in the prompt, if you have told Ubuntu on installation. If you work on another distribution, it should be configured (or configurable) in /etc/hosts too, as the address 127.0.0.1.

Copy files

The scp command is a replica of the cp one, but it works over the network via SSH connections, transfering files bidirectionally as long as you execute it from the client. Remote file locations are described by prefixes like Desmond:/home/giorgio:

scp Desmond:~/file.txt .

scp works trasparently, but tells you the completion percentage and the ETA. It would be handy to have these measures locally. You can always ssh to yourself, but I doubt the efficiency of that operation just to get scp statistics on transfer.

There's more

GNU screen is another handy utility to run in SSH connections, as it's able to keep your processes running even when you close the connection.

SSH tunnels are also another quite wide topic, and are created in order to encapsulate other level 7 protocols into SSH connections. That goes farther than the Git example: HTTP proxies can be bypassed by sending HTTP traffic into a tunnel. However the scope of this article is not so broad to include this: I about only about tried-and-tested things I setup on every machine in my LAN at each new installation.

Feel free to add your SSH tips and practices in the comments.