1. Foreword
  2. Key Generation
    1. Name Considerations
  3. Copying the Key
  4. Hardening Authentication
  5. Applying the Changes
  6. Optional: SSHFS
    1. Usage
    2. Considerations

Foreword⌗

This guide assumes prior knowledge, up to this point, all you’ll need is a client system with utilities such as ssh and an empty server that you have root access to. The end state of this guide will be to have a secure OpenBSD server that only YOU can log into with your private key. Password authentication will be completely disabled. This will allow us a good platform to do things on it later, should we decide.

Key Generation⌗

For this, we will utilize elliptic curve cryptography to generate a key. the -a in the command indicates number of passes with the goal of increasing entropy. Upon execution of the command below, it will prompt you for input to name the key. Feel free to name it whatever you want.

$ ssh-keygen -t ed25519 -a 512
...
# Enter desired keypair name

Now that generation is complete, both the private and public keys will exist in your ~/.ssh/ directory, with the latter ending in .pub.

Name Considerations⌗

If you opted to not to name your key and went with the default, feel free to move on to the next section. If you did name it however, bear in mind that from here on out we will have to add an extra argument on every ssh and sshfs command in order for them to select your key. By default, these commands will only parse the hardcoded default keynames and ignore your custom named key.

Copying the Key⌗

Let’s utilize SSH to copy our public key to the server. By default, this will take whatever public key is in ~/.ssh/ and send it to our server’s /root/.ssh/authorized_keys file as a text entry. Let’s do that now.

Remember to replace ed25519.pub with whatever the actual name of your .pub file is that you just generated, as well as replacing 11.11.11.11 with your actual server’s IP.

# The -i operand will parse your local ~/.ssh/ directory
# for the named "ed25519.pub" file that immedietly follows
$ ssh-copy-id -i ~/.ssh/ed25519.pub root@11.11.11.11

now you may SSH into your server

$ ssh -i ~/.ssh/ed25519 root@11.11.11.11

to verify the keypair has been added, cat the following directory

$ cat /root/.ssh/authorized_keys

the above file is the one that stores authorized public keys. now we will navigate to the SSH settings to lock down all logins via username/password.

Hardening Authentication⌗

now we will change the ssh settings on our server to ensure only we are able to log into it, and no one else. keep in mind that if you lose your private key, you will lose access to your server. it is heavily encouraged that you not only keep regular backups of your server’s data, but you backup your private key in a location only you have access to; i.e a LUKS Volume

SSH system authentication is governed in /etc/ssh/sshd_config, we will edit that in order to disable password authentication and enforcing private key authentication - of which only your private key will be accepted

$ vi /etc/ssh/sshd_config
...
ChallengeResponseAuthentication no
PasswordAuthentication no

Applying the Changes⌗

now with this, we must restart sshd, to do this we will utilize rcctl. this will cause the changes to the authentication mechanism to come into effect.

$ rcctl restart sshd

you may now exit the ssh session by typing exit, this will send you back to your local terminal. to log back in, we will utilize the SSH command.

by default, public key authentication is disabled, to counteract this, we will be using the -i argument when logging in over SSH in order to log in with our named key. if you have named your key anything other than the default, ensure you replace ed25519 with whatever your actual key’s name is.

$ ssh -i ~/.ssh/ed25519 root@11.11.11.11

Optional: SSHFS⌗

SSHFS is a tool that allows you to browse your server as though it was a storage device plugged into your PC - but over SSH. This is incredibly convenient and allows small teams/sole sysads to sidestep the need for FTP and/or similar protocols.

Depending on your distro, the package may be called fuse-sshfs or simply sshfs, let’s discuss it’s usage.

Usage⌗

Below is the most straightforward way to utilize sshfs. This will simply mount the named location on your server to the specified mountpoint, treating it exactly like media you were to mount via the local mount command.

$ mkdir ~/servername
$ sshfs root@11.11.11.11:/ /home/username/servername/ -o IdentityFile=/home/username/.ssh/privatekey

The “:/” after the ssh login block indicates where in the server you wish to mount. in the example, it will mount the root of the server’s filesystem. You could replace it with an exact location if you know exactly where you want to go. The second block will mount the server to the named folder servername in the user’s home directory. Replace this block with the actual location you want the server mounted. The final block is telling sshfs exactly where your private key is.

To end the sshfs session, utilize the fusermount command.

$ fusermount -u /home/username/servername

Considerations⌗

SSHFS will mount the whatever server directory you give it exactly like mount. If you attempt to delete the directory recursively, you will begin deleting files inside of the directory, effectively beginning to wipe your server.