how to secure OpenSSH
As discussed in my earlier articles on how to secure wordpress server and other LAMP application servers (part I, part II), it is imperative to protect the big ‘L’ in the LAMP, the Linux host server itself. One main step is to restrict and secure access to the server. On a Linux server, OpenSSH (sometimes in couple with a VPN solution) is the most commonly vetted choice. It should be used in lieu of telnet and FTP.
The OpenSSH that comes with mainstream Linux distributions may not be as tailored as you want to afford maximum security you desired. This should not be much of a surprise, since any pre-packaged software needs to reach broader audience and wider range of use cases, plus the packager may not share the same information security principles as you and may assess the risks differently.
So, how to secure SSH, or how to secure OpenSSH, you’d ask. Below, we’ll examine what feature/options are available to provide better security for a stock installation of OpenSSH under CentOS 4 Linux and FC6 (Fedora Core 6) Linux. Here are steps on how to secure OpenSSH (SSH) by adjusting and tweaking /etc/ssh/sshd_config, the main OpenSSH server configuration file.
- Disable support for SSH protocol version 1.
SSH v1 support is built-in for backward compatibility, not for security. v1 protocol has inherent weakness and is much less used or tested to have a robust implementation.
#Protocol 2,1
Protocol 2
- disallow root login.
Direct remote access by privileged users always poses greater security risk. For specific tasks that has to be done by root, you may want to set it to ‘forced-commands-only’ to allow that specific command be executed, exactly as specified by the corresponding public key entry in authorized_keys or authorized_keys2.
Before activating this change, make sure you have set up at least one regular user account and verified this user can ssh in and gain elevated privileges.
PermitRootLogin no
- disallow authentication by password.
The password will be tunneled in as clear text. Worse, authentication by login and password combo is vulnerable to brutal-force attack or dictionary attack.
Before you activate this option, make sure you’ve set up and verified authentication by public key. Otherwise you may lock yourself out.
PasswordAuthentication no
- disable s/key passwords
If you don’t have or use S/KEY on your site. In the past, it had security problems. To adhere to the minimalist maxim, why would you choose to expose to potential risk of a feature, when you don’t even need or use such a feature.
ChallengeResponseAuthentication no
- disallow TCP forwarding
SSH has a powerful feature called ‘TCP Forwarding”. X11Forwarding is its special form. It can tunnel arbitrary TCP traffic inside an established SSH session. Such TCP traffic normally would be scrutinized, filtered, denied access, audited, and monitored by network security gears on your site such as a corporate firewall, routers, proxy servers, etc.
AllowTcpForwarding no
X11Forwarding no
- limit who has access
A Linux server has many built-in accounts. Various third-party applications may require even mofe to be added. Even real users don’t have to have SSH access. For instance, a POP3 account user could have regular shell account, but he/she should have access to only the POP3 service.
For OpenSSH, you can restrict access to an explicit list of users identified by ‘AllowUsers’ or an explicit list of user groups identified by ‘AllowGroups’. Note, this is a deny-by-default configuration. For an allow-by-default configuration, you should use ‘DenyUsers’ and ‘DenyGroups’ instead.
AllowUsers user1 user2
AllowGroups sshGroup1 sshGroup2
- set up a banner to serve legal notice for SSH service
The man page for sshd_config said it well, “In some jurisdictions, sending a warning message before authentication may be relevant for getting legal protection. The contents of the specified file are sent to the remote user before authentication is allowed. This option is only available for protocol version 2.”
banner /etc/ssh/ssh_legal_notice
- Many other directives are available.
In modern Linux distributions such as CentOS 4 and FC 6 (Fedora Core Linux 6), many OpenSSH server options already have sane and secure values by default. For example,
PrintLastLog yes
PermitEmptyPasswords no
PermitTunnel no
SyslogFacility auth
UseDNS yes
StricktModes yes
UsePrivilegeSeparation yes
- Noteworthy points
- There are more advanced settings we’ll discuss later, such as interface to listen to and protocol family, limit on number of authenticaiton attempts and time, and etc. Plus, you could/should use firewall to restrict access to the SSH service too.
- Needless to say, the same set of configurations and thinking apply to OpenSSH server installation on other operating systems too, such as a Cygwin port of OpenSSH server on a Windows Server, or UNIX servers (Solaris, SCO Unix, HP-UX), etc.
