How to do SSH properly

Thu, 16 Jan 2025 04:22:58 +0000

The things people get wrong

When configuring SSH an incredible amount of servers aren’t set up correctly and this causes them to be extremely vulnerable to even automated attacks. Common mistakes include failing to disable root login, permitting password-based authentication instead of key-based authentication and more.

Install OpenSSH server

First install openssh on your machine. You can usually do this on Ubuntu based distro using sudo apt install openssh-server. Now before enabling the initially vulnerable service it’s time to make some changes.

Let’s get editing!

Using your favourite text editor edit (with admin privileges) /etc/ssh/sshd_config on the server. By default it most likely looks similar to this:

Include /etc/ssh/sshd_config.d/*.conf

# This is the sshd server system-wide configuration file.  See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/local/sbin:/usr/local/bin:/usr/bin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented.  Uncommented options override the
# default value.

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

# Ciphers and keying
#RekeyLimit default none

# Logging
#SyslogFacility AUTH
#LogLevel INFO

# Authentication:

#LoginGraceTime 2m
#PermitRootLogin prohibit-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10

#PubkeyAuthentication yes

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile	.ssh/authorized_keys

#AuthorizedPrincipalsFile none

#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody

# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes

# To disable tunneled clear text passwords, change to no here!
#PasswordAuthentication yes
#PermitEmptyPasswords no

# Change to no to disable s/key passwords
#KbdInteractiveAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the KbdInteractiveAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via KbdInteractiveAuthentication may bypass
# the setting of "PermitRootLogin prohibit-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and KbdInteractiveAuthentication to 'no'.
#UsePAM no

#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
#X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS no
#PidFile /run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none

# no default banner path
#Banner none

# override default of no subsystems
Subsystem	sftp	/usr/lib/ssh/sftp-server

# Example of overriding settings on a per-user basis
#Match User anoncvs
#	X11Forwarding no
#	AllowTcpForwarding no
#	PermitTTY no
#	ForceCommand cvs server

Change the default port

The first thing I recommend changing is the SSH port you use. This isn’t necessarily something that should be relied on to protect you as it’s security through obscurity however if there are vulnerabilties in OpenSSH (which there have been in the past) then there’s a smaller chance automated bots will find your SSH server. This is because they traditionally look for port 22 and if they do scan for other ports they often wouldn’t scan to a really high port such as 9057 for instance; they typically only scan up to 1000.

Another benefit is that it will keep your logs down as they will get rather big if they’re logging automated attacks which try to authenticate with your SSH server. Fortunately they likely won’t reach your actual SSH port and so the only logs generated will generally be from your own activity which often is smaller than a hundred or so requests a day from bots. To do this change #Port 22 to Port 7845 or whatever port you choose.

There’s a line which says: #PermitRootLogin prohibit-password. Adjust this to #PermitRootLogin no. This prevents logging into root (essentially the admin account) via SSH. Much safer! Note that it is possible to only allow specific users to be signed in via SSH but that’s out of the scope of this guide and not really necesssary.

Disable password authentication

Another crucial line to change if not the most important is: #PasswordAuthentication yes. This needs to be set to PasswordAuthentication no. Wonderful!

Set up Fail2Ban

Fail2Ban is a great piece of kit designed to mitigate brute-force attacks (where an attacker will try different combinations until they guess the right password/ key to gain access). Essentially it allows us to ban an IP address of an attacker using various rule-sets. To install it run sudo apt install fail2ban. Now the configuration file can be found at /etc/fail2ban/jail.conf however when the package is update this will be overwritten and there it’s not recommended to edit this file directly. Instead create a copy in the same directory called jail.local. To do this run the following command: sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local. Now you can edit the file using administrator privileges. Under the “Jails” section you should find sshd. As shown below:

#
# JAILS
#

#
# SSH servers
#

[sshd]

# To use more aggressive sshd modes set filter parameter "mode" in jail.local:
# normal (default), ddos, extra or aggressive (combines all).
# See "tests/files/logs/sshd" or "filter.d/sshd.conf" for usage example and details.
#mode   = normal
port    = ssh
logpath = %(sshd_log)s
backend = %(sshd_backend)s

If you changed the SSH port in the previous step then adjust that here e.g. port = 7845. I recommend changing the bantime to at least an hour. To do this edit the following:

# "bantime" is the amount of time that a host is banned, integer in seconds or
# time abbreviation format (m - minutes, h - hours, d - days, w - weeks, mo - months, y - years).
# This is to consider as an initial time if bantime.increment gets enabled.
bantime  = 10m

# A host is banned if it has generated "maxretry" during the last "findtime"
# seconds.
findtime  = 10m

# "maxretry" is the number of failures before a host get banned.
maxretry = 5

You can adjust bantime to your liking e.g. bantime = 1h will set it to one hour. There’s a lot more you can do with fail2ban and formulas you can tinker with which dynamically change the ban time expondentially for repeat offenders but we’ll leave it there for now. Save the file and run sudo systemctl enable fail2ban --now.

To test this works you can actually abuse your SSH server (when we’ve enabled it later) and see if you get banned (although I recommend setting the bantime to 1m if you’re going to do this). To test it, simply try to login to your SSH server with the wrong username and identity key (more on that later) several times.

You can see the status of bans by running sudo fail2ban-client status sshd.

Generate some SSH keys

At this point it would probably be a good idea to generate some SSH keys. On your client machine (the one you want to use to connect to your SSH server) run ssh-keygen set the filename to something memorable such as “mediaserver” and press enter. Then add a password - this encrypts your private key ensuring that even if somebody got hold of it, they’d be unable to access your SSH server (providing the password was strong enough). It’s an extra step but isn’t necessary as long as you feel the files on your computer are secure!!! Are they!?

Type ls into the terminal and you should see two files mediasever and mediaserver.pub (or whatever you named them). Move these to the .ssh folder in the home directory using the following command mkdir -p ~/.ssh/keys && mv mediaserver mediaserver.pub ~/.ssh/keys - this command makes the .ssh directory in the home folder if it doesn’t already exist and then moves the ssh keys to a folder called “keys” inside of the .ssh directory. Your directory structure should look like this:

.ssh
└── keys
    ├── mediaserver
    └── mediaserver.pub

2 directories, 2 files

Now let’s change the permission of the files to ensure they’re kept extra safe chmod 600 ~/.ssh/keys/*. This ensures only the owner of the file has read and write permission.

The mediaserver file is the private key (this must be kept secret and NEVER shared with anyone else). The mediaserver.pub key is the public key and this can be shared anywhere without consequences. We need to take the contents of mediaserver.pub and append them (add as a new line) to a file on our server found at ~/.ssh/authorized_keys. Feel free to add this to GitHub or a pastepin service and download it onto the server. I recommend copying the files contents as follows: cat ~/.ssh/keys/mediaserver.pub. Make sure to copy this exactly and create a paste here. You should have a link like this https://pastebin.com/raw/VAuQ6qta (note the raw part of the URL is rather important for the next step). Now go to your server and execute the following curl https://pastebin.com/raw/VAuQ6qta >> ~/.ssh/authorized_keys. Curl will grab the contents and then add it as a new line to the authorized_keys file (and create the file if it didn’t already exist). Note that >> means append but > means overwrite (which is only harmful if you already had keys in there).

Now it’s time to start your SSH server with sudo systemctl enable sshd --now.

A note about firewalls

You’ll also need to change any firewall settings. If you haven’t got a firewall installed already then install one with sudo apt install ufw. This will install Uncomplicated Firewall. Allow your SSH port with sudo ufw allow 7845/tcp (or whatever port you chose). Now enable the firewall with sudo ufw enable. If you want to see the firewall rules run sudo ufw status. To delete them run sudo ufw status numbered and then sudo ufw delete NUMBER where “NUMBER” is the rule you wish to delete. You can also reset it with sudo ufw reset but please note this will deactivate it and you’ll need to run sudo ufw enable again to reinstate it. If you want to establish an SSH connection outside of your home network then you’ll also need to port forward the appropriate port.

If all is well you should be able to log in on your client machine with ssh -p 7845 -i ~/.ssh/keys/mediaserver myserverusername@myIPAddress. The -p 7845 stands for the port you wish to use (if you didn’t change it from 22 you can leave this out) and -i specifies the identity file required to authorize the connection.

Managing SSH keys

Running ssh -p 7845 -i ~/.ssh/keys/mediaserver myserverusername@myIPAddress can become rather tedious, especially if you need to connect to multiple machines, remember all of their identity files, individual ports etc. To mitiate this create a file in ~/.ssh/config. Inside add the following:

Host mediaserver
    User myserverusername
    Port 7845
    IdentityFile ~/.ssh/keys/mediaserver
    HostName myIPAddress

This then allows you to run ssh mediaserver and you’ll be able to connect to your server just like that. Note that the name “mediaserver” is whatever you specify as the “Host” - you can literally call it anything and it can be different from the key names or username.

To add more ssh connections edit the file as follows:

Host mediaserver
    User myserverusername
    Port 7845
    IdentityFile ~/.ssh/keys/mediaserver
    HostName myIPAddress
Host linode-vps
    User oden
    Port 5034
    IdentityFile ~/.ssh/keys/linode
    HostName 203.0.113.45

We can now connect to our Linode VPS (Virtual Private Server - basically a machine running what’s usually Ubuntu in the cloud).

Congratulations 🥳

Well done! You have successfully (I hope) set up SSH securely and learnt to manage SSH keys. If you’d like to create an SSH connection without port forwarding or firewall rules then I suggest looking into Cloudflare tunnels or TailScale.

Ssh on