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.
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:
apt install unattended-upgrades
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.
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
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.
Tip 4: Explitly Allow Users
Whitelisting user accounts and denying all others adds more protection around misconfigured accounts.
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.
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.
Helpful client configuration in
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.
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
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?
iptables -A INPUT -p tcp --dport 22 -s 184.108.40.206 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j REJECT --reject-with icmp-host-prohibitied
Limit user keys to specific hosts in
from="example.foobar.com,220.127.116.11,2500:5523::1" ssh-dss AAAA...== email@example.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:
You might want to also remove small Diffie-Hellman keys:
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:
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.
If you have made changes to your
sshd_config file then be sure to restart
sshd and test them out:
systemctl restart sshd