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.
- You can change the port used by default, for example: Port 222. In any case, remember to open this port in the firewall and redirect it to the router. It is not necessarily essential.
- Very important, remove root's ability to connect in SSH with this line, in order to avoid bruteforce attacks directly on the "root" username:
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:
- It is much more secure.
- It avoids writing a password every time 😎.
- This is useful to run ssh commands in scripts.
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:
- ~/.ssh/sshkey: this is your private key, NEVER share it with anyone.
- ~/.ssh/sshkey.pub: the public key. Contrary to its name, it is like a lock that only the private key can enter.
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