Tired Of SSH Attacks 2021-02-24
I recently received an email from someone asking about how to stem the tide of SSH attacks from China. SSH is basically a utility that allows you to open a terminal on a remote computer and interact with it on a command line as if you were sitting at it. It is what allows a goof like me to manage a server in a datacenter somewhere without having to put on pants and leave the house. Anyways, I figured that rather than just replying with my answer I may as well post it for anyone else who may have the same question(s).
There is a dog in this image (click for full size).So... here are a few things you can do to reduce your SSH related irritation:
1. Use key authentication and disable password authentication. Basically, SSH provides a way for you to login with a "key" instead of a password. Typical SSH attacks are password attempts and will be blocked if you disable password auth. A key might look something like this:
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn
NhAAAAAwEAAQAAAQEAvlMqX+gscrD/PLwRqyBa+94taDkYgFSaq+32P+RXpFodfGxf6ndj
iwkdH3qTMlJX4z9XhTjItxZRwEMB84xAvuArokGtlIcbueoEHTuYrmawErPD+iv8MXITdZ
...
A+RXSFknzWvfTHfnWHFIyxCnZWqLWxn0PTDzjx+Y+/VFNZQiCpo37agArd+iUt5854TFPq
VR5ofY5FQxZHfokAAAAKdXNlckBteWJveAE=
-----END OPENSSH PRIVATE KEY-----
There are lots of tutorials like this one and this other one explaining how to set this up. There are lots of fancy things you can do with this kind of setup and I'd suggest also looking at how to make a ~/.ssh/config file with tutorials like this one and this other one.
2. Use fail2ban to block repeated attempts. fail2ban is an application that monitors your log files looking for "bad activity"... when it finds bad stuff it can perform actions (usually banning the IP address temporarily with a firewall rule). The idea is that if a failed login comes from the same IP address a few times in less than a minute it is probably a hack attempt and that IP can be blocked for an hour or a day or whatever you like. fail2ban is pretty powerful and can be used to manage any kind of log events you want. It is a good idea to get to know fail2ban, not just for SSH but for any services you may have on your server.
3. Move SSH off port 22. There are LOTS of people who will get a bad case of puckering butt symdrome when they read this, but they're dead inside. People just LOVE to claim that "security by obscurity isn't security at all". Well, that simply isn't the case. The VAST majority of SSH attacks will be looking at port 22, and by moving it off port 22 means fewer attempts at guessing your password. It also means fewer log entries for crappy attempts, and ultimately less packets landing at your server (because many scripts don't know there is anything there to attack). I'll happily agree that if this is the ONLY method of security you attempt to use then it probably won't work out well in the long run, but it it IS useful whether it is obscurity or not.
4. Use a firewall to allow only your IP address access to SSH. Basically if you block all access to SSH by default and then allow only your IP address, attackers will not be able to tell there is an SSH service listening at all. I personally use manual iptables rules, you may have some fancy firewall application that came with your distribution, or you may even have some fancy web interface that allows you to click checkboxes and type in textboxes to setup blocking. Now if you have a static IP address at home you can just "block-all and then allow-you", if you have a dynamic IP address at home (or if you travel to various other networks) then you may need to either (1) use a dynamic DNS service to point to the IP address you are currently at or (2) use a jumphost that does have a static IP.
Ultimately it makes sense to use multiple strategies to reduce your SSH pain. I would think that #1 is a bare minimum, #2 slows down the attempts significantly, #3 reduces the number of attempts significantly, and #4 is very effective but requires that you figure out the firewalling. Bottom line, it isn't hard to mitigate SSH risk, but it does require some work and a willingness to learn.