How I access servers via SSH (including SFTP, SSHFS and mosh)

It's always wise to take security into our own hands as much as possible as well as reducing the amount of connections we establish with servers. This guide will walk you through how to check how much entropy is available, generate RSA keys, use least SSH connections possible whilst getting the most out of them and overall make things easier.

The scenario is that we want to type ssh foo and be prompted for an RSA key passthrase and be able to run that command multiple times for multiple shells but only ever have one SSH connection open to the server which will reduce overhead.

Checking the amount of entropy available to you

Entropy is a measurement of the random numbers available from /dev/urandom, entropy is measured in bits and if the amount of entropy available to you is less than 100-200 bits then there is a chance that your keys will be weaker than you think. The command below will return the amount of entropy (in bits) that your system has available to you. You can populate /dev/urandom with garbage by wiggling your mouse, pressing keys and basically using your system while you generate keys, the more under strain your system is when performing cryptographic operations, the better. Systems which most commonly suffer from entropy exhaustion are VMs (Virtual Machines) which depend on a lot of virtual hardware and have a lack of physical hardware.

$ cat /proc/sys/kernel/random/entropy_avail

Generating our RSA keys

Next we're going to generate our very own 4096 bit RSA keys like so, it will ask for a passphrase, it's recommended that you input one else anyone who gets access to your private key can use it to log into your stuff.

$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/foo_rsa

If all went well, in the ~/.ssh/ directory, you should have two files

Private key: ~/.ssh/foo_rsa
Public key: ~/.ssh/

Your private key must NEVER be shared because that would be like sharing your password, same goes for the passphrase you set on it.

Your public key is what you hand out.

It is also recommended that you use a different RSA key per server, that way if a server gets compromised then you only have to generate a single new key for that server when it gets restored.

Generating a second set of RSA keys is simple, you just choose a different file name.

$ ssh-keygen -t rsa -b 4096 -f ~/.ssh/bar_rsa

Copying our RSA keys to the system

This next part can be tricky depending on the configuration of the OpenSSH server, OpenSSH can be configured to not accept passwords as an authentication method, if so then that leaves the option of key-based authentication such as RSA, DSA, etc. If this is the case then you are required to contact the server administrator and send them your public key file so they can add it to the server, fortunately however, Ctrl-C club doesn't have this enforcement in place and so you can just proceed onto the next step.

Keys can be simply copied to the server like so.

$ ssh-copy-id -i ~/.ssh/ foo

If all went well, the copying process should have placed your public key as an entry into the ~/.ssh/authorized_keys file on the server.

Multiplexing a single SSH connection to utilise it better and reduce overhead on the server

Since around 2007, OpenSSHv2 connections have been multiplexable, that means you can run multiple sessions over a single SSH connection which reduces overhead on the server and speeds up the initiation of second and so on sessions. How OpenSSH does this is via an option called ControlMaster, this enables the sharing of multiple sessions over a single connection.

You first need to ensure you have the ~/.ssh/controlmasters/ directory and if not, create it.

$ mkdir ~/.ssh/controlmasters/

Define a host with default parameters for OpenSSH client to make life easier and reduce on typing

Add the following to ~/.ssh/config and personalise the options, if the Host option is foo then you will type ssh foo when accessing the system instead of the usual hostname. Bare in mind that these parameters are defaults and you can specify flags to the ssh command to override them, you can also pass a username like you normally would do.

Host foo
        User your_username
        IdentityFile ~/.ssh/foo_rsa
        ControlPath ~/.ssh/controlmasters/%r@%h:%p
        ControlMaster auto
        ControlPersist 10m

SSHing in!

First time you type ssh foo it will be as slow as usual and it will prompt for your passphrase if you set one, each time after that, sessions will be started faster and you won't be prompted for a password.

File transfers

Just incase you didn't know, you can do file transfers over SSH using the SFTP protocol like so:

$ sftp foo

Create a file system in user space with SSHFS

First create a directory to use as our mount point, give it any name you want like so:

$ mkdir ~/sshfs

Now to mount the file system like so:

$ sshfs foo:/home/remote_username ~/sshfs

And once you're done, unmount the filesystem like so:

$ fusermount -u ~/sshfs

Terrible internet connection? Using a mobile device?

Please note: This option does not work with SSH connection multiplexing and you will understand why when you read on.

If you have a terrible internet connection or have a lot of drop outs due to always being on the move mosh (Mobile Shell) may be an option for you however it has to be installed both server and client side.

Mosh initially connects to the server via SSH and then executes mosh-server. Mosh then uses SSH to exchange the required keys before terminating the SSH session. mosh-client is then told to connect to a UDP port opened by mosh-server.

Bare in mind that mosh uses a UDP port range of 60000 to 61000 and some system administrators may be cringy about that because that's a 1000 ports dedicated to a single purpose. Each connection equates to a mosh-server instance which equates to a UDP port in that range being used up.

When your internet connection is lost and re-established, mosh-client will attempt to re-establish a connection with the UDP port opened by its corresponding mosh-server instance.

$ mosh foo

Closing the SSH connection

Exiting all your SSH sessions is not enough because your SSH connection is running in the background and so you need to manually close it. Closing SSH connections is recommended each time you've finished with your SSH sessions else you are leaving an open door for anyone to wonder onto your sessions. The way to do that is like so:

$ ssh -O exit foo

Check for an open SSH connection

$ ssh -O check foo

And don't forget to read the manpages

Before putting the extra effort in of asking a person or group of people for advice, make sure to check the manpages first, if a solution to your problem can be found in the manpages then checking there first will reduce your time looking for answers to your problems, avoids the situation of having to wait on people for answers, avoids the situation of having to scroll through webpages and search results. Basically work smarter, not harder.

$ man ssh
$ man ssh-keygen
$ man ssh-copy-id
$ man mosh
$ man sftp
$ man sshfs

And enjoy messing around!