Secure Shell ssh - the Swiss Army Knife of Remote Access

(2014-12-13, updated 2023-03-08) See newer version

Resources
Usage patterns

Survival in the wild is no problem if you carry your Swiss Army Knife. So is survival in the internet – provided you know ssh.

Cybertool knife by Victorinox © Rama

Resources

Cheat Sheet
Wikipedia Entry
Man pages (OpenSSH on Debian Linux; mostly works for all Linux + MacOSX): ssh, scp, ssh-agent, ssh-keygen, ssh_config
ssh on Microsoft Windows: putty, WinSCP
ssh on Android, iOS

Usage patterns

Secure shell is a tool for remote access to computers connected to the internet.

Remote access with password authentication

Assume your your sysadmin told you "Just use ssh to gate in order to log in to the institute". Then your institute which has the internet domain institute.com probably has a host gate.institute.com. Then this should work:

mylaptop$ ssh user@gate.institute.com
user@gate.institute.com's password: 
Last login: Thu Dec 11 17:46:16 2014 from dslb-188-103-172-167.188.103.pools.vodafone-ip.de

As a result you will see the shell prompt of the remote system.

If this is the first connection from the computer you are working on to the institute, you will be asked if you really trust the identity (which you probably do at this point - if you don't, you can e.g. phone the sysadmin and ask her to read the fingerprint for comparison):

mylaptop$ ssh user@gate.institute.com
The authenticity of host 'gate.institute.com (180.95.11.140)' 
can't be established.
RSA1 key fingerprint is ce:e0:70:ea:7c:d4:e1:99:09:61:bd:0b:28:46:08:6b.
Are you sure you want to continue connecting (yes/no)?

After answering yes, you get

Warning: Permanently added 'gate.institute.de,180.95.11.140' 
(RSA1) to the list of known hosts.

Similarly, this authentication check may be issued after a re-install of the remote system. If nothing of this is the case, this might be a warning sign for a man-in-the middle attack.

After setting up this communication channel, all communication will be encrypted using a temporary symmetric session key which is automatically negotiated after authentication.

Copying data

Along with the secure shell suite comes the command scp which allows you to copy data between computers. Fetching a file from the remote host using an absolute path goes like that:

scp user@gate.institute.com:/home/user/daten.dat daten.dat .

Fetching a file from your home directory on the remote host goes like

scp user@gate.institute.com:daten.dat .

Likewise, you can copy data from your computer to the remote host:

scp daten.dat user@gate.institute.com:/home/user/daten.dat
scp daten.dat user@gate.institute.com:

Of course, every time you will be asked for your password...

Executing commands on the remote host

As an example,

ssh user@gate.institute.com ls

executes the command ls on the remote host. For interactive commands, you should use the -t switch:

ssh -t user@gate.institute.com  emacs -nw

If it is an X11 program, you can get encrypted transport to X11 windows by adding -X to the command line:

ssh -X user@gate.institute.com  emacs

Of course, every time you will be asked for your password...

Public key authentication

Now, we want to get rid of these annoying password requests. This can be done by providing the remote host with an "ssh public key". Also, services like github and gitlab allow to add an "ssh public key" for easier authentication.

In order to prepare this, you need to generate a private-public key pair. The secure shell suite provides the command ssh-keygen which does this job:

mylaptop$ ssh-keygen
Generating public/private rsa1 key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):*************** 
Enter same passphrase again:***************
Your identification has been saved in /home/user/.ssh/id_rsa
Your public key has been saved in /home/user/.ssh/id_rsa.pub
The key fingerprint is:
5c:23:da:14:00:c6:6f:3f:6e:2d:69:26:e2:9c:60:b0 user@nmnb2

The private key is protected by the passphrase and marks your identity if activated. Both private key and passphrase should be kept safe. They are not meant to be given to others.

The public key is used to check this identity. You give it to anyone (computer or person) whom you want to enable to do this check.

In particular, you can add this public key to the contents of the file .ssh/authorized_keys in your home directory on the remote host (e.g. gate.institute.com). To do this, use scp to copy the key and ssh to log in to the remote and to edit the file. In the result, the contents of that file will look like

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCvyyza7e8tFrBhNMRd/3w+XL9PIeSNTUC+PcHOQI7kcfk4oTDnfysTkPleM3fM+r588sDRWKa7eivLoZ7NCF3EgMd0HUUVHjWbWZgF7KXylu4dcsDMvANH5BlgWysFqxzaTzy8CX8E03NYSkn5kqzgtnkIm+Z/QzLd4mq48oG9Ns3uPlhU4Wf2XGEqV/6EtLvHgAG/PtUP1kofO74oit2d8BH3fkU0UCMBlZqVCAoefFnR4qg3c18McK3dGhM741dpopeD3E+zaJ55AS9nIZFdbkOZNsrQR+FbzmwkqQDwQ060De5XijqdU3VD64xxHeQeFtgHG/LqAOCaUTzVtKzx fuhrmann@jfzbook.wias-berlin.de

Be sure, that the whole subdirectory .ssh is readable only by yourself. To ensure this, issue

chmod -R go-rwx .ssh

from the home directory on the remote host.

Then you can login using

mylaptop$ ssh -i .ssh/id_rsa gate.institute.com
Enter passphrase for RSA key 'user@nmnb2':

So, now you authenticate with the passphrase instead of the remote password.

You can store as many public keys in .ssh/authorized_keys as you like, thus giving access to your account to other identities of yours (e.g. form other computers) or to other people (wich you should'nt do). Just add the line by line. Be careful not to break the keys by accidental insertion of a line break. Each key uses exactly one line.

Behind this implemenatation lies the idea of public-key cryptography.

Nice... but still I have to activate my key every time I want to use it...

Password-less login: identity management by ssh-agent

Communicating with ssh-agent, the command ssh-add activates your private key for automatic use by ssh after verifying your passphrase:

mylaptop$ ssh-add
Need passphrase for .ssh/id_rsa
Enter passphrase for user@nmnb2 
Identity added: .ssh/id_rsa (user@nmnb2)

The identity is then activated throughout your desktop session. Now try to issue

ssh user@gate.institute.com

If everything works, you will be logged in without password or passphrase request. The ssh-agent provides the activated identity to the remote host, which uses the public key to check for the match.

As long as you keep your passphrase and your private key safe, the connection is encrypted and the procedure is as safe as you can get using current technology (provided all participating systems are regularly updated). You can increase security by specifying higher key lengths and more sophisticated cipher schemes when generating your key pair, and by specifying a more advanced cipher for the session keys using the -c flag of ssh.

Modern desktop systems automatically start the ssh-agent, so probably you do not have to care about this. In times long passed you would have done this yourself by issuing e.g. one of

$ ssh-agent xterm
$ ssh-agent bash
$ ssh-agent twm

Every decent Swiss Army Knife has a couple of strange tools whose purpose seems to be beyond your imagination. Same with ssh:

Tunneling
Config file
Host name aliasing in config file
Single command execution during public key access
Virtual Private Network (VPN) support
ssh daemon

About some of these may be later...

Marginalia