SSH Server Setup
SSH client/server installation
One of the first things you want to do when setting up a server is to allow remote access through Secure SHell (SSH). This program allows clients to securely remote in and run commands on the host system. First to install the program on the server/host:
sudo apt install ssh-server
This will create a config file in /etc/ssh/sshd_config, which will hold all the juicy security settings on our server. Before diving in, lets install the ssh service on our client:
sudo apt install ssh-client
This will allow us to log in to the host server with ssh [email protected] where host_user is the username to log into on the host system and ssh.server.ip is the local IP of the ssh server, obtained by running ip addr. This will prompt us for the password of the user we're logging into, and after succesfully logging in, success!
SSH keys
However, a user-entered password is quite weak in terms of security, and it would be painful to enter the password each time we want to log in. This is where we introduce the beautiful concept of SSH keys, which is exactly like a key to your home, allowing you to access your server. The power of keys is the use of encryption to secure the key contents, the convenience of skipping the password login, and more importantly, the ability to disable weak user-entered passwords altogether!
To generate a key, all we need to do is run:
ssh-keygen
where you can specify where to save the keys to, as well as a passphrase (better for security, but not required). This creates two files by default under $HOME/.ssh/, id_rsa the private key and id_rsa.pub the public key. id_rsa contains the identity that makes you.. well YOU! As such, this should NEVER be shared with others or else they can mask themselves as you. Additionally, the only user on the client with access to this private key should be the user. This concept is so important that some servers will outright reject your key pair if your private key is insecure. Luckily, this settings are the default. Imagine this file as the physical key used to enter your home.
In contrast, the key generation also generates id_rsa.pub. This key can be shared anywhere, and is used to validate the user logging in. This key is analogous to the lock(s) used to enter your home.
So now we have our key made, how do we let our server know to use this key to log in? There is another simple command to copy the public key contents to the host server:
ssh-copy-id -i /path/to/ssh_key.pub [email protected]
This will copy the contents of the public key file into the host server's $HOME/.ssh/authorized_keys file. You could, of course do this manually or physically, but this command makes it easy. To make sure this worked, try logging into the server again. This time, there shouldn't be a prompt for a user entered password! Success!
Server Security
We have a secure and encrypted way to log in to our server now, however, we MAY want to access our server outside of our local home network. It is especially important to take security measures into account, as script kiddies scrape larges ranges of public IP addresses for networks with open access to SSH networks.
This is where the real power of using keys comes in: If we ONLY allow logging in with keys and disable password login, then we make it virtually impossible for foreign logins to occur. For context, an RSA encrypted key requires so many factorizations to break it would take a classical computer MANY years to guess the corresponding private key (of course quantum computers could break this, but who owns one of those nowadays? And even then, there are other key algorithms, ecdsa or ed25519 that haven't been theorized to be cracked by quantum computers).
So to secure our SSH server, we go back to the /etc/ssh/sshd_config file we mentioned earlier. There are two vital settings to instantly secure our server:
PasswordAuthentication no PubkeyAuthentication yes
Disabling password authentication makes it so the only way to log in is using the user-provided key whose public key is within the host server's authorized_keys file. be careful enabling this as you won't be able to login without your public key in the authorized keys file!. After editing the config file, you'll need to restart the SSH service using:
sudo systemctl restart ssh
And just like that you have exclusive access to your server! you can try logging in from a different system or using a dummy ssh key and you'll be denied. Of course, others will not be able to log in or copy-id unless you add their public key to the host server's authorized_keys list.
It is worthwhile to explore other options in the sshd_config file. Most will be reserved for an advanced tutorial, involving ciphers, KEX, and MACS outlined in the Mozilla openssh standards. But the few that are easily useful are:
MaxAuthTries 3 MaxSessions 3
which limits the amount of attempts at logging in and the maximum amount of people able to log in at once. There are programs to blacklist IPs who persistently login such as fail2ban that I've yet to explore, but this helps ensure a soft limit on login attempts.
There is an option to specify a non-default port, but I've been told it doesn't necessarily help with security due to the nature of script kiddies scraping all ports
Hopefully this long writeup is comprehensive enough for the first step in your home server journey. I'll write up ways to securely access your server outside of your home network either through open ports or cloudflare, as well as advanced security options and my notes on encryption methods.