Solved SSH Hardening
-
What do you do beyond disable root and require keys? Anything?
Normally, this is all I do with
/etc/ssh/sshd_config
PermitRootLogin no PubkeyAuthentication yes PasswordAuthentication no
This is for a system with port 22 available on the public internet. Obviously
fail2ban
is in place.This is my typical
bundy_jail.local
sshd section.[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 enabled = true action = %(action_mw)s
-
That's all that we do. You can only do so much to harden something that has to be exposed.
-
Last place I was we had to set only certain ciphers and MACs, had banners, etc but that was a specific case. We also did limit the SSH access to only be from the config management server to not allow people to log into the VMs. The workstations were able to be SSH'd into.
-
Also fail2ban isn't going to do anything with only key auth. The access gets denied before it has a chance to do anything.
I found this out the hard way when I was essentially DOS'd from remotely accessing my system when someone did actually attempt to break in. The load on the system spiked for around 2 hours.
-
Here was a topic I had posted a while back: https://mangolassi.it/topic/10391/fairly-hardened-jump-box (I didn't realize fail2ban would be essentially useless with keys when I posted this). The password required was the system password, not the key password.
Using 2FA is a good option too. I use my Yubikey with Duo or the phone one touch response from Duo for access to my systems.
The advantage to the extra hardening is it's essentially invisible to you (other than the 2FA and password requirement obv).
-
@stacksofplates said in SSH Hardening:
Also fail2ban isn't going to do anything with only key auth. The access gets denied before it has a chance to do anything.
Actually, it still catches it. I tested that.
At least on Fedora using
systemd
it does. -
@stacksofplates first hit on a new one I just setup. The system that prompted me to make this post in fact. I forgot to install
whois
, that is fixed now. -
@stacksofplates said in SSH Hardening:
Here was a topic I had posted a while back
Good post, but total overkill to me. What is the point of the connection from an IT point of view if not to manage the system? Yet your hardening restricts any administration except at the local console.
I log in to systems via SSH in order to reboot them, or update WTF ever application they are running. Tasks that your security will stop.
-
@JaredBusch said in SSH Hardening:
@stacksofplates said in SSH Hardening:
Here was a topic I had posted a while back
Good post, but total overkill to me. What is the point of the connection from an IT point of view if not to manage the system? Yet your hardening restricts any administration except at the local console.
I log in to systems via SSH in order to reboot them, or update WTF ever application they are running. Tasks that your security will stop.
You mean you don't want to drive to every client site/data center/home office and update things from the comfort of their own space?
-
Install Lynis, it'll audit your SSH config and suggest areas to improve.
-
@JaredBusch said in SSH Hardening:
@stacksofplates said in SSH Hardening:
Here was a topic I had posted a while back
Good post, but total overkill to me. What is the point of the connection from an IT point of view if not to manage the system? Yet your hardening restricts any administration except at the local console.
I log in to systems via SSH in order to reboot them, or update WTF ever application they are running. Tasks that your security will stop.
That was just a jump box. It was a way to get in to other stuff to do the admin. It is overkill for you just had ideas if you wanted them.
-
@JaredBusch said in SSH Hardening:
@stacksofplates said in SSH Hardening:
Also fail2ban isn't going to do anything with only key auth. The access gets denied before it has a chance to do anything.
Actually, it still catches it. I tested that.
At least on Fedora using
systemd
it does.Ah they must have changed it. It used to be SSH denied the request before it ever hit PAM so fail2ban did nothing.
-
@stacksofplates said in SSH Hardening:
@JaredBusch said in SSH Hardening:
@stacksofplates said in SSH Hardening:
Also fail2ban isn't going to do anything with only key auth. The access gets denied before it has a chance to do anything.
Actually, it still catches it. I tested that.
At least on Fedora using
systemd
it does.Ah they must have changed it. It used to be SSH denied the request before it ever hit PAM so fail2ban did nothing.
I also could have set it up wrong but I thought I remembered someone else saying the same thing on stack exchange or somewhere.
-
@stacksofplates said in SSH Hardening:
@JaredBusch said in SSH Hardening:
@stacksofplates said in SSH Hardening:
Here was a topic I had posted a while back
Good post, but total overkill to me. What is the point of the connection from an IT point of view if not to manage the system? Yet your hardening restricts any administration except at the local console.
I log in to systems via SSH in order to reboot them, or update WTF ever application they are running. Tasks that your security will stop.
That was just a jump box. It was a way to get in to other stuff to do the admin. It is overkill for you just had ideas if you wanted them.
Definitely a good post with good ideas.
-
@JaredBusch said in SSH Hardening:
[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
Note, the commented out
#mode = normal
. If you change that toddos
, it will also causefail2ban
to log failed attempts to the disabled root account, and valid users with invalid, or no, key. -
So I set this up again on a new jump box today.
SSH attempts did not log until I changed the mode to
ddos