This post is about Hardening SSH Configuration
Introduction
SSH has become the standard tool for remote management of UNIX-based systems. The SSH daemon (sshd) is installed on almost all of the major systems by default. Additionally, sshd also provides a lot of configuration options for us.
Note: This article is a continuation of my previous topic about Lynis. Although I have tried to make this readable on its own. You might want to consider reading the previous one to get some context.
The default settings of openssh (the version of SSH developed by the OpenBSD project) follows the “secure by default” philosophy so most of the configurations are safe on their own. However, on performing the lynis audit scan I have received some suggestion about the configurations. So let’s go over the suggestions in order to further harden our SSH daemon. I will also comment on whether turning some of them off/on improves any security.
Hardening SSH Configuration
The suggestions include modifying our sshd configuration. As the default path for the sshd config is /etc/ssh/sshd_config, that is where we should look.
TCP and Agent Forwarding
As can be seen from the screenshot, lynis recommends we set AllowTCPForwarding and AllowAgentForwarding to no. It’s a good advice to only use what is required so we should disable this option if we aren’t using it. However, disabling this will not improve security if a user has shell access in which case they can setup their own forwarders (as pointed out by the sshd_config(5) manual page).
ClientAliveCountMax
ClientAliveCountMax and ClientAliveInterval are two related options. The count max, multiplied with the client alive interval in seconds, determines when a connection has become unresponsive. I don’t see how this would affect security. Perhaps, I need to do more research. Nonetheless, lowering the value shouldn’t hurt.
Compression
SSH allows us to compress data sent after authentication via this option. On slow modems, compression may improve the connection speeds. However, on most modern systems enabling this shouldn’t have an effect. Furthermore, it may also introduce us to BREACH attacks as pointed out in this GitHub comment. Therefore, let’s take lynis' suggestion.
LogLevel
sshd logs messages to journald by default on most GNU/Linux distributions. This option control the level of details that is to be logged. lynis recommends setting this from INFO to VERBOSE which may help in troubleshooting, etc. The manual page of sshd_config(5) points out, however, that setting to a higher level (eg. DEBUG) may violate the privacy of its users. So, I really don’t see any improvement in security by tweaking this setting.
MaxAuthTries
This value determines how many authentication attempts to permit per connection. Moreover, when the connection attempt failures reach half of this value, then sshd will start logging the failures. Ergo, it makes sense to lower this value.
MaxSessions
The value of this option specifies how many shell sessions are to be permitted per connection. I don’t think one may need to ssh into a single server multiple times at ones. Moreover, there’s also tmux which allows us to do the multiplexing we want without opening multiple sessions. So, it makes sense to take this suggestion.
Port
My interpretation of this suggestion is that we should set the sshd listening port to some other value. This will prove useful to defend against most botnets which are scanning the internet looking for vulnerable machines on default ports. However, anyone who knows the basics of network mapping (tools like nmap) will know that this won’t help. Nonetheless, let’s set it to a non-default value.
TCPKeepAlive
Setting this option to YES will help the server notice when a connection has died. That way sessions don’t hang indefinitely on the server. Therefore, I think it’s better not to disable this option.
X11Forwarding
Although, most ssh sessions are meant to be only text based. However, openssh also provides the feature to open GUI applications on the server which will be displayed on the client. The way it works is that the X server opens a channel back to the client. The problem with this is, X11 was never designed with security in mind. It assumes that all programs are trusted since they were run by us. But, as this answer points out, with X11Forwarding, the server can control the client and thus be able to execute shell commands on the client. So, we better turn this feature if we don’t need it.
Conclusion
As always, security is a very complicated topic. We can’t always know when a system is secure. Furthermore, the appearance of security is even worse than no security.
In this article, I went over the various configurations including even the very minor details that could help improve security of our ssh server. But as always, harden your system as per your threat model.
So you know about Hardening SSH Configuration
