Operating OpenSSH

,

Is OpenSSH safe to leave open on the Internet?

I’ve read the first Google page worth of results on the question so let me summarize.

The short answer is no.

The long answer is complicated and involves risk. The articles that suggested how to operate OpenSSH safely on the Internet generally offered the tips below.

this is fine meme

Tip -1: Hide Behind a VPN

Multiple layers of security bring many benefits. This article is talking about running OpenSSH directly available on the public Internet but consider wrapping your traffic in Wireguard or OpenVPN or even a random Big Name security provider’s VPN.

Tip 0: Enable Automatic Upgrades

You have to be running patched and up to date versions of software otherwise the game is lost before it starts. On Debian, there are unattended upgrades:

1
2
apt install unattended-upgrades
systemctl enable unattended-upgrades.service

Update your OS today!

Tip 1: Disable Root Logins

Disable direct network access to the root account by delegating privileges using sudo to specific users.

In /etc/ssh/sshd_config:

1
PermitRootLogin no

Background on sudo from the Arch Linux Wiki

Tip 2: Force OpenSSH Protocol Version 2

A wealth of improvement and hardening comes from ensuring your OpenSSH server only speaks the latest protocol version.

At the top of /etc/ssh/sshd_config:

1
Protocol 2

Tip 3: Disable Empty Passwords

This prevents misconfigured users from getting in over the network and is the default, but it is good to double check.

In /etc/ssh/sshd_config:

1
PermitEmptyPasswords no

Tip 4: Explitly Allow Users

Whitelisting user accounts and denying all others adds more protection around misconfigured accounts.

In /etc/ssh/sshd_config:

1
AllowUsers bob alice joe nagios

Tip 5: Disable Password Authentication

OpenSSH comes with a wealth of tools for managing machine and user encrpytion keys. They can be protected in numerous ways and even get shielded in hardware devices plus restricted and revoked server side. In short, replacing password authenticatioin with key-based authentication provides a lot of benefit.

In /etc/ssh/sshd_config:

1
2
PasswordAuthentication no
ChallengeResponseAuthentication no

A tutorial on setting up basic user OpenSSH keys: here

Tip 6: Changing The Server Port Number

If your goal is to reduce log spam from people attempting to bruteforce their way in, with usernames and passwords you have whitelisted and disabled, then changing which port OpenSSH listens on or which outside port your router forwards from will help.

A very simple port scan will find it though so it offers no additional safety.

In /etc/ssh/sshd_config:

1
Port 2222

Helpful client configuration in ssh_config:

1
2
Host example.public.com
    Port 2222

Tip 7: Rate Limit Connections

Modern OSs and OpenSSH can handle a lot of noise but putting a hard cap on resource utilization can be a good idea.

In /etc/ssh/sshd_config:

1
2
MaxAuthTries 3
MaxStartups 2:30:10

Or with iptables:

1
2
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name ssh-resource
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent ! --update --seconds 90 --hitcount 3 --name ssh-resource -j LOGDROP

I set MaxAuthTries 3, leave MaxStartups at its default, and configure iptables very generously to only slow down the aggressively, pointlessly misconfigured bots.

Tip 8: Limit Connections to Known Hosts

Again another tip recommending reducing who talks to OpenSSH but maybe you will like this flavor, this time, a few paragraphs down, better?

Using iptables:

1
2
iptables -A INPUT -p tcp --dport 22 -s 5.4.6.7 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with icmp-host-prohibitied

Limit user keys to specific hosts in authorized_keys files:

1
from="example.foobar.com,34.34.1.3,2500:5523::1" ssh-dss AAAA...== user@laptop.foobar.com

Note: There are many useful restrictions that can be placed on keys in your authorized_keys files. Check out the documentation here and section “AUTHORIZED_KEYS FILE FORMAT” here.

Tip 9: fail2ban

If you have to allow passwords in any fashion, fail2ban will be useful and you can find helpful people over there. It can be used to set fine-grained policies around people trying to brute force passwords to get in.

Tip 10: Host Identification

Explicitly gathering and verifying the host keys of your OpenSSH servers provides extra guarantees against man-in-the-middle attacks. OpenSSH’s default policy is called trust on first use and generally works well but setting up your known_hosts file is another layer of safety you can wrap around OpenSSH.

You might even consider an OpenSSH Certificate Authority to automate trusting host keys.

Tip 11: Stronger Cryptography

Modern OpenSSH supports “legacy” cryptography to support older clients for interoperability. The list changes over time as your OpenSSH gets patched and upgraded, but these seem like the current bestest choices at this moment to improve strength and nuke backwards compatibility:

1
2
3
Ciphers aes256-gcm@openssh.com,aes256-ctr
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-512

You might want to also remove small Diffie-Hellman keys:

1
2
awk '$5 >= 3071' /etc/ssh/moduli > /etc/ssh/moduli.safe
mv /etc/ssh/moduli.safe /etc/ssh/moduli

Tip 12: Correct Time

Everything on the Internet works best with the correct time.

I recommend Chrony and your OS should get you somewhere sane enough:

1
2
3
apt install chrony
systemctl enable chrony
systemctl start chrony

But network time can be complicated.

Also check out the public NTP Pool Project if you want to know how the Internet keeps time.

Wrap up

If you have made changes to your sshd_config file then be sure to restart sshd and test them out:

1
systemctl restart sshd