SSH: administer remotely

Configuring SSH

SSH is a great tool 🙋. You can access to your server from another computer. You can then manage it remotely without having to connect a keyboard and screen. Truth be told, with some exceptions, all servers are administered this way, but you are at home after all, so you can do whatever you want.

SSH is a protocol useful for much more: encrypted tunnels, SFTP file storage space...

Anyway, if you didn't enable SSH when installing OpenBSD, you can enable it with the following command:

# rcctl enable sshd

Although this protocol is reliable, it does not cost anything to take some safety precautions. We will edit the SSH configuration in the /etc/ssh/sshd_config file.

PermitRootLogin no

To connect to the machine, you will need to create a simple user with the "adduser" command.

Once the changes have been made, restart the SSH daemon:

# rcctl reload sshd

Later, to connect to the server, you will use the following command from your computer (in a terminal, or with a client like putty under windows):

$ ssh toto@chezmoi.tld

And if you changed the default port:

$ ssh -p 222 toto@chezmoi.tld

It will ask for the password of the user toto, then you can administer the server remotely.

Login with keys (without password)

It is quite possible to connect in SSH without using a password. Instead, we use a pair of keys. This is a good idea at least for the following reasons:

However, this requires you to have the private key on the device used to connect, which is not always the case.

Here's the procedure to follow :

On the server, edit the /etc/ssh/sshd_config file so it contains this line:

PubkeyAuthentication yes

Now, on the computer that is used to access the server, we will generate a key pair with the following command:

ssh-keygen -t ed25519 -f ~/.ssh/sshkey -a 100

You will find two new files:

The ed25519 algorithm is suggested because it is very reliable at the moment.

Do not enter a password and then wait for the keys to be generated.

On an OpenBSD or Linux system, you will take care to edit your user's ~/.ssh/config file to fill it out as follows:

Host your_server
HostName verylong.reallylong.too.long
User myusername
Port 222
PasswordAuthentication no
IdentityFile ~/.ssh/sshkey

Of course, you will change the domain name of your server as well as the name of the user who must connect. Then run the following command to copy the public key to the server.

ssh-copy-id -p xxx -i ~/.ssh/sshkey.pub "myusername@verylong.reallylong.too.long"

Here, replace "xxx" with the port used by SSH if it's not 22.

If the ssh-copy-id tool is not available, you must copy the public key manually. To display it, type

$ cat ~/.ssh/sshkey.pub

Connect to the server in SSH, then add in the file ~/.ssh/authorized_keys the contents of the file displayed previously.

Once this is done, you can log in without having to enter a password with just the command:

$ ssh your_server

Convenient, isn't it?

If that works as expected, you can disable password identification for good so that only the keyset is left as possibilities. Edit the /etc/ssh/sshd_config file to contain this line:

PasswordAuthentication no

BE CAREFUL not to lose your set of keys!

Upload a file

You will definitely need to upload files to your server from time to time. Once SSH is configured, you will be able to use the scp command from any computer to copy a file to your server. For example :

$ scp -P <ssh port> user@athome.tld:/location/from/destination file-to-copy

It's very useful.

However, if you want to transfer many files, backup or store documents, consider SFTP instead, which has more features such as resuming a partial transfer.

If the files are too large, you can split them for multiple transfers.

SSHFP DNS records

The first time you connect to your server using SSH, the client get the fingerprint of the server. Next time, it compares the previous checkprint and display a warning if it has changed because there might be a problem if you didn't touch your server since. It's called Trust On First Use (TOFU -- not the food, sorry).

To avoid TOFU, you can publish data necessary to check the fingerprint the first time. To do so, we use a DNS SSHFP record.

Enter "ssh-keygen -r athome.tld" and copy the result in your DNS zone. Don't forget to adjust the entries with a final dot "." after domain name or replacing it with a "@" if necessary.

As example :

@ IN SSHFP 1 1 97f5a9479fd16fbee1381c425297f7b2773a67a4
@ IN SSHFP 1 2 bd50a3c271e83dc769ea7c249a5c07aea1a817c62910129de56eba2763f93607
@ IN SSHFP 2 1 05fb8516842fc270ea5abda38d1c32b41e75da8a
@ IN SSHFP 2 2 491489437e137d7d27959a4de3ba7660185ef98cbd3abc2287c82f82e8f032ab
@ IN SSHFP 3 1 b7305417b0e981c4513642020a1f57ee03915af5
@ IN SSHFP 3 2 f15d33852df5f4043c77b6bf1c6134a5e11de0a513c1ec127fcbb8fae733b178
@ IN SSHFP 4 1 a1120fe90e69c0f534fece3dc837db6a262c3371
@ IN SSHFP 4 2 a36e418b517d95a74f1e0be1228d46e7aeaa8ed310359e91162d8c40b373eb55

We'll talk about DNS a bit further 😉.

In order the client check these records with the server fingerprint at first connection, add option "VerifyHostKeyDNS" to ssh. In "~/.ssh/config" :

Host *
    VerifyHostKeyDNS yes