Configuring SSH

= How to Generate and Install SSH Keys =

This section describes how to generate and install SSH keys in order to access a remote server from your client PC without SSH password authentication. This increases security and comfort.

Generate the Key Pair
First of all, think about how the file pair should be named:


 * Filenames should have prefix id_rsa_ per convention.


 * It is best to properly name the keys. The key name usually contains the name of the remote system. This way, it is easy to discard private keys for remote systems that do not exist anymore. You may want the mention of the local system too in the key name, if you plan to use one key per PC.


 * A date in the filename helps easily discard old key files with lost private key counterparts.

The following Bash commands generate a good filename (and a similar key comment) with a minimum of fuss:

TMPSTR="username_description_$(date "+%Y_%m_%d")" ssh-keygen -t rsa  -P &apos;&apos;  -b 4096  -C "$TMPSTR"  -f "$HOME/.ssh/id_rsa_$TMPSTR"

In the command above:
 * -b 4096   is the key length
 * -P &apos;&apos;   means no password You can password-protect the private key file at the cost of convenience. The ssh-agent can help reduce prompting.
 * -C   is the comment placed inside the .pub files

Two key files with names like these are generated:

id_rsa_username_description_2019_21_01     (private key) id_rsa_username_description_2019_21_01.pub (public  key)

On Microsoft Windows, you can use graphical tools PuTTYgen or KiTTY -keygen to generate the key pair.

Copy the Public Key to the Server
The following Bash command places a copy of the public key on the remote server:

ssh-copy-id -i "$HOME/.ssh/id_rsa_$TMPSTR"  -p 22  username@remotepc.com

In the command above, -p 22 is the TCP port number where the SSH server is listening on. This is normally TCP port 22, but it may vary for security reasons.

Alternatively, you can manually append the contents of the .pub key file to ~/.ssh/authorized_keys on the server using your favourite text editor.

Tool ssh-copy-id does not work on OpenWrt routers using the Dropbear SSH server. For these systems, either manually edit the /etc/dropbear/authorized_keys file, or use the following command:

ssh -p 22  username@remotepc.com  "cat - >> /etc/dropbear/authorized_keys"  <"$HOME/.ssh/id_rsa_$TMPSTR.pub"

When doing this manually, or with the alternative ssh commands above, there are a number of things you have to look out for. Directory ~/.ssh may not exist on the server yet. File permissions on that directory and in any files inside it may need to be more restrictive than usual. And watch out for missing end-of-line characters when automatically appending text with cat to the authorized_keys file. Tool ssh-copy-id does all that automatically.

Try the New Key
ssh -p 22  -i "$HOME/.ssh/id_rsa_$TMPSTR"  username@remotepc.com

Consider Backing up the Key Pair Outside Your Current PC
This is important if you decide to disable SSH password authentication on the server for security reasons. If you then lose your private key, you may not be able to remotely log on to the server anymore.

Copying the Private Key File to Another Computer
If you copy the private key file to another client computer, make sure the user is the owner of that file (which is usually the case), and that the file permissions are more restrictive than usual, or the private key file will not be used:

chown $USER ~/.ssh/id_rsa_username_description_2019_21_01 chmod 0600 ~/.ssh/id_rsa_username_description_2019_21_01

Permissions 0600 mean -rw--- (only the owner can read and write).

Edit ~/.ssh/config
Create or edit file ~/.ssh/config on your client PC in order to avoid having to specify the "ssh -i" argument and other connection options every time.

This is an example ~/.ssh/config file:

Host * # Only use the files explicitly mentioned. Otherwise, the SSH client # will try all keys until one works. This can easily lead to confusion. IdentitiesOnly yes Host MyRemotePc HostName remotepc.com Port 22 User username IdentityFile /home/username/.ssh/id_rsa_username_description_2019_21_01 CheckHostIP no
 * 1) Indentation below is not mandatory, but it improves readability.
 * 1) Defaults for all hosts.
 * 1) - 'Host' is just a friendly name. You can use the same address
 * 2)   as in HostName.
 * 3) - 'User' is the username on the remote machine.
 * 4) - 'CheckHostIP' can normally be turned off with little security
 * 5)   implications. Otherwise, you will get a security prompt every time
 * 6)   the server IP changes, which you may find annoying.
 * 7) - Optionally add "StrictHostKeyChecking no" if frequent prompting
 * 8)   on an experimental network bugs you.

Note that the ~/.ssh/config file will not be used unless it has the right owner and permissions:

chown $USER ~/.ssh/config chmod 600  ~/.ssh/config

Permissions 0600 mean -rw--- (only the owner can read and write).