SSH

SSH (secure shell) is a secure networking tool used between a client and a server. Using an encrypted network protocol, it can be used to securely login to a server remotely, as well as for more advanded networking scenarios. Typical use cases for SSH include:

  • Access to a server’s console shell, remotely.
  • Transfer files between the server and client (using rsync, scp, or sftp).
  • Create network tunnels to access private servers, in both directions, either on the server, or on the client.
  • Create a server that acts as a bastion or “jump” host, to be a port of entry into a larger private network. SSH is configured to only allow authorized client keys access through the bastion host.
  • Create a server to act as an HTTP (socks) client proxy, to allow remote clients to browse the web, using the server’s IP address as the origin.
  • Remote controlling a Docker server using the docker command line client (SSH Docker Context).

SSH is based upon public key cryptography. Both the client and the server need to create their own public/private keypair. Keys can be encrypted on disk (eg. ~/.ssh/id_ecdsa) or they may also be loaded from a USB hardware token. Upon connecting to a remote server for the first time, the client asks the user to validate the server’s public key fingerprint, and then the server’s public key is written into a file called ~/.ssh/known_hosts, which marks the connection as trusted from then on. The server also authorizes the client through a predefined authorized_keys file. If either side rejects the key presented by the other, the connection is unauthorized, and is closed immediately.

Create SSH Keys

This book recommends the use of hardware authentication tokens, like the Solokey. Traditional SSH keyfiles are also acceptable, but these should be considered as a legacy format, as they are less secure. Finally, plain password authentication (non-key based) is fully deprecated and should never be used.

Setup Solokey (FIDO2) hardware authentication

Plug in your Solokey (or compatible hardware) to the USB port.

Initialize the hardware with a new SSH key:

[bash]: Run this on your workstation:
## You only need to do this one time per solokey!
ssh-keygen -t ed25519-sk -O resident -O verify-required

You will be required to create/enter a PIN for the Solokey.

Traditional SSH keyfiles

The Solokey still has some drawbacks, and cannot be used in all cases. Traditional SSH keyfiles are still useful for automated and unattended clients. Technically, the solokey is supposed to be able to work in a “touchless” mode, by using the -O no-touch-required option, but I never got this to work.

Key files should be created uniquely for each user and workstation. They should never be shared between multiple users or workstations.

Choosing the SSH key type

It is recommended to use the newer ed25519 key type, which uses the latest encryption standards. Your distribution may still use the older standard rsa by default (which is acceptable). You should explicitly select the key type when creating the keyfile to be sure.

Some older servers don’t accpet ed25519 keys, and so in those cases you should still create an rsa key as well. Each key type is stored in a different file, so its OK to have multiple types installed on the same machine.

Create the new SSH keys

Create the rsa key type:

[bash]: Run this on your workstation:
ssh-keygen -t rsa -f ~/.ssh/id_rsa

Create the ed25519 key type:

[bash]: Run this on your workstation:
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519

You will be prompted to enter an encryption passphrase for each file, which you should definitely not skip!

Setup the ssh-agent

Because your keyfiles are encrypted with a passphrase, you need to enter the passphrase everytime you use it. This is inconvenient, so you can run ssh-agent to temporarily store your key/identity in memory, and therefore you only need to enter your passphrase once, when you log in. (In the case of the solokey, the key is never held in memory, but you still need to hold the identity of it in the ssh-agent.)

Keychain is a program that helps you setup the ssh-agent. Install keychain in each of your toolboxes and/or workstations:

Run this on your Fedora workstations:
sudo dnf install keychain
Run this on your Debian / Ubuntu workstations:
sudo apt install keychain
Run this on your Arch Linux workstations:
sudo pacman -S keychain

To configure keychain, edit your ~/.bashrc file:

Edit this file: ~/.bashrc
## Put this line in your ~/.bashrc:
## (If you're using my config, this is already in it.)
eval $(keychain --eval --quiet)

Log out of your desktop session, and log back in. Open your terminal, and you should be automatically prompted to enter your SSH passphrase. Once you have entered the passphrase, the SSH key will remain resident in memory until you log out.

Double check that the key has been loaded, run:

run this inside your toolbox
ssh-add -L

The above should print your public key, loaded into the running ssh-agent. Now you should be able to use your key without entering a passphrase. Copy the output and upload it to your services as your authorized key. For servers, put the key into ~/.ssh/authorized_keys. For hosted services, like GitHub, paste the key into your SSH settings page.

Add your solokey identity per session

Apparently, keychain does not yet know how to load the Solokey automatically. You must add the Solokey to the ssh-agent manually, one time, each time you boot your workstation:

run this inside your toolbox
## Do this to load your Solokey into the ssh-agent:
ssh-add -K

You will be prompted one time to enter your Solokey pin to unlock the key.