Remote connections through SSH

Go to:

Introduction Top

SSH is the acronym for Secure SHell, a protocol that allows to remotely connect to a computer and to work on it using the command line (see e.g. this tutorial). The SSH connection is encrypted, so that the data cannot be sniffed by someone else.

The basic usage allows to connect to the shell of the computer target with 

 user@home:~$ ssh username@target
and inserting the user password.

Sometimes, however, one needs to connect to a node that is in a subnetwork, and it may be necessary to enter firstly a intermediate node and then to enter the desider computer. For example, one may be at home and need to connect to the office PC, that is in the internal network. The necessary steps are then (home) → (public access point) → (office) .
The most obvious way to connect to the internal network node office is to SSH to the first node and then from this to the second node: 

user@home:~$ ssh username@public
username@public:~$ ssh username@office

or in one line: 
user@home:~$ ssh username@public ssh username@office
.
This sequence, without any adjustment, has two disadvantages, that can be easily solved: you have to enter twice the password and you have to SSH twice. If there is a third step, the number of passages increases. Let's see how to simplify the process.

Using the SSH keys Top

In order to login without the need to enter the password all the times, it's possible to generate and authorize a SSH key. Each key has two parts: a public and a private key. When you connect to a remote system, the SSH protocol compares your public key with the keys that have been previously authorized. If your key is one of these, you don't need to insert your password.

To create your pair of public and private SSH keys, you can use 

user@home:~$ ssh-keygen -t rsa

that generates the .ssh/id_rsa.pub and .ssh/id_rsa files. The former contains the public keys, that must be authorized on the remote hosts, while the latter contains the private key, that instead should be protected, never sent through the web and never copied to other computers.

The process asks if you want to insert a passphrase. The advantage of the passphrase is that the key cannot be used by anyone that does not know which passphrase you used to encrypt the keys. The disadvantage is that you have to insert the passphrase each time you login through SSH using the key. The passphrase, differently from a password, is never transmitted to the remote server, because it is only needed by your local system to decrypt the private key.

The generated key must then be copied into the remote hosts to which one wants to connect. The process requires, for example, a command such as: 

user@home:~$ ssh-copy-id username@public
.
The ssh-copy-id command copies the public key into the ~/.ssh/authorized_keys file in the remote public system. From now on, each time you SSH to public, you will not be asked for your password in the remote host (but eventually for the passphrase).


More details can be found, for example, here.

The .ssh/config file Top

Many useful settings related to SSH can be saved in the .ssh/config file. For example, you can avoid inserting your username or using shortcuts for the hostname you want to connect. Assume that you want to connect to the public access point of the Torino INFN network from your home. The command is: 

user@home:~$ ssh username@to01xl.to.infn.it
.
You can simplify it using these settings in the .ssh/config file in your home system:
Host to01xl publicINFNTo
  user username
  HostName to01xl.to.infn.it
.
In this way, you can either use to01xl or publicINFNTo as a shortcut for to01xl.to.infn.it. You can also avoid writing the username in the SSH command:
user@home:~$ ssh to01xl

or 
user@home:~$ ssh publicINFNTo
.

The SSH config file, however, is much more useful to do more complex things. Let's consider again the case presented before, where we had to do an intermediate step to SSH the office pc. The intermediate step can be embedded in the .ssh/config file in this way: 

Host public
  user username1
  HostName public.servername.ext

Host office
  user username2
  HostName office_host_username2
  ProxyCommand ssh public -W %h:%p 2> /dev/null

Here, a different username is used for the public login machine and the office host, both of them having a complex name that is replaced by a short name. The ProxyCommand tells the SSH client that you can connect to office using the public node as an intermediate passage. Please note that you can extend the chain adding a series of intermediate nodes, each with its appropriate ProxyCommand: if your connection requires to do (home) → (intermediate1) → (intermediate2) → (target), you can set 
Host intermediate1
  user username1
  HostName intermediate1.server.ext

Host intermediate2
  user username2
  HostName intermediate2.full.hostname
  ProxyCommand ssh intermediate1 -W %h:%p 2> /dev/null

Host office
  user username3
  HostName office_host_username2
  ProxyCommand ssh intermediate2 -W %h:%p 2> /dev/null
.

After this, you can simply connect from your home pc to the office pc using: 

user@home:~$ ssh office
.
If you have properly installed the SSH keys, you will enter the office pc without having to write the passwords and the intermediate steps. This is particularly interesting if you want to copy files to the office pc with scp, as 
user@home:~$ scp localfile.txt office:path/to/folder/remotefile.txt
,
or to sync entire folders with rsync as in 
user@home:~$ rsync -auvz office:remote/folder/ local/folder/
.

 

The .ssh/config file is useful also for other reasons.

One may want to use graphycal software from another computer, through SSH: it is necessary to enable the forwarding of the graphycal interface over SSH, inserting into the .ssh/config file the option: 

ForwardX11 yes
.
One may also want avoid a connection fault for short network problems: in this case you can set a timer (20 seconds in the example) and a number of attempts (3) that the SSH client will do before the connection is considered lost: 
ServerAliveInterval 20
ServerAliveCountMax 3
.

Much more on the options that can be defined in the .ssh/config file is in the man page: 

man sshd_config
.

sshfs Top

Another useful thing that you can do with ssh is mounting a remote directory as a filesystem. This clearly works well if the network is fast and if you don't have to read/write a large amount of data.

For example, suppose that in the computer hostPC you have a very large folder (~/data/) that you want to use from a different computer, workerPC, that is on the same local network. What you have to do is to create a new empty folder inside workerPC: 

user@workerPC:~$ mkdir data_remote

and then you can connect the remote folder in hostPC to the new directory:
user@workerPC:~$ sshfs hostPC:/path/to/data/ data_remote/
.

To unmount the remote directory, the command is 

user@workerPC:~$ fusermount -u data_remote/
.