voidcruiser.nl/content/rambles/ssh-configuration.md

title	date	author	tags	description	draft
SSH Configuration	2022-09-27T11:40:31+02:00	$HUMANOID	ssh technology	An article on configuring SSH from the ground up to something that can grow out into my monster of a configuration	true

Introduction

If you're anything like me, you'll have at least a hand full of servers you'll log into (at least) every now and then using SSH. These servers don't all have the same key. And on top of that, I frequently have multiple keys per host. Managing this by hand is a pain in the arse. Thankfully there are a few tools that make it a breeze. I will be going through what I have done to both my local configuration and what I tend to do with my server configuration.

Generating keys

In order to do anything with SSH in a secure way, you'll need to make use of public and private keys. These keypairs are generated using ssh-keygen. I typically generate mine using:

ssh-keygen -t ed25519 -f ~/.ssh/<new-key>

Without any parameters, it will generate an rsa3072 key. This form of cryptography isn't the recommended as it's become a bit flimsy with computers becoming stronger. Instead I recommend at least adding the -t ed25519 flag to generate a ed25519 key instead.

When prompted for a passphrase, always give it one. The only reason where not using a passphrase is acceptable is when you are planning on using the key for a forced command.

Server Configuration

This is all done under the assumption that the you use OpenSSH implementation on your server. If you use something like Dropbear, I can't help you as haven't properly dug through it's configuration file (yet).

The thing I see way to often on the internet is

• People not disabling password authentication.
• Changing the default port or only allowing.
• Don't disable root login and never use it.

So lets go through these steps one by one.

Password Authentication

Password authentication is the most basic thing every server should have disabled. Otherwise, it is possible to brute force a connection into your server.

"But my server is not exposed to the internet."

I guess you could get away with not disabling password authentication, but it's still not a good idea in case, say, your network gets compromised. On top of that, it's less convenient to have to type in a password every time you want to log into your server (more in that in the SSH Agent section).

In order to disable password authentication, open your SSH daemon configuration file: /etc/ssh/sshd_config and look for the following lines...

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

...uncomment PasswordAuthentication and replace "yes" for "no". Make sure you still have a way into your server before restarting the daemon.

If you're not planning on logging in as the root user, uncomment and set the following setting to "no"

...
#PermitRootLogin prohibit-password
...

Be aware of the fact that you can still utilise the root account using sudo su - (assuming you're using sudo on your server, else use whatever other privilege escalation tool you have at hand).

Restarting the daemon on modern systems is usually done using:

systemctl restart sshd

If you're not using systemd, I'm sure you know what command to use instead.

Adding keys to authorized_keys

When going through /etc/ssh/sshd_config you've probably come across a few lines resembling:

...
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile     .ssh/authorized_keys .ssh/authorized_keys2
...

This means that the SSH daemon will check in .ssh/authorized_keys in the home directory of the user as whom you're trying to log in for public keys. So the next step is to append your public key to this file in the home directory of the user as whom you want to be able to log in. This can be done in a few ways. The proper way is by using:

ssh-copy-id -i ~/.ssh/<key-file> <user>@<host>

I'm usually too lazy to use the proper way and just open the file in vi paste it in there by hand during the same initial login where I'm disabling password authentication. Either way works fine.

Changing the port

The advantage to this is that your logs will be a lot cleaner if your host is exposed to the internet. There are large amounts of bots hammering port 22 on every IP address they can find with common usernames and passwords like "root" and "admin". A solution next to this is to use fail2ban along side changing the port.

"Won't this mean I have to add the port to my login command every time I go to this server?"

No, more in this in [the client configuration] section

In /etc/ssh/sshd_config look for

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

and change the Port to your liking, I tend to change this to something like 6969 or some other meme number.

Another thing I tend to do is not open a port in my firewall, thus preventing any normal outside connections all together. Instead opting to only connecting over Yggdrasil and/or Tor.

Client configuration

If people tend not to think much about their server configuration, their client configuration is probably not even touched at all.

The ~/.ssh/config file

The very first thing I do after setting up a server, is add an entry to my ~/.ssh/config in order to manage its key, the user, the port and possibly subdomain should the need arise.

A basic configuration section looks like the following:

Host <host> # this is something you can easily identify
	Host <hostname> # this does need to be an IP address or DNS record pointing to an IP address
	IdentityFile ~/.ssh/<key-file>
	User <username>
	Port 6969

This allows you to log into host <host> with on port 6969 with key ~/.ssh/<key-file> as user <username> without by typing:

ssh <username>@<hostname> -p 6969 -i ~/.ssh/<key-file>

Instead the following command will work:

ssh <host>

Some other frequently used settings for me are:

• AddKeysToAgent
• IdentitiesOnly
• ProxyCommand

AddKeysToAgent

Automatically adds the key to your SSH agent if you have one running.

This is useful if you frequently log in and out of a certain host and don't want to take the time to add it's key to your agent manually.

IdentitiesOnly

Ignore whatever keys your agent has and only use the contents of IdentityFile.

Useful for when you want to be able to log into the same host using multiple keys.

ProxyCommand

Always connect to your host using a proxy.

Useful for when you can only access a host through a certain proxy.

I use this for my Tor hosts:

Host tor-<host>
        Hostname <lengthy-56-character-string>.onion
        ProxyCommand nc -X 5 -x localhost:9050 %h %p # this assumes you are running a tor proxy on your local system and attempts to make a connection through that
        Identityfile ~/.ssh/<key-file>
        User <user>