Securing a linux server : hardening SSH – Intermediate

Try it in our public cloud & Get $50 Credit

Long ago there was Telnet, an unsecure, text based remote shell protocol that allowed to connect to  remote servers. However, being clear-text based, anyone on the line was able to either sniff packet or do man in the middle attack and get the data being carried between the client and the server. The Secure Shell (SSH) was created to fix these flaws as the web was becoming a dangerous place to live. However, even if SSH is inherently more secure, a misconfigured SSH service constitutes a security hole in your server’s defence.

Here are some tips you should follow.

Don’t allow root login

disallow root user

This is one thing that is often repeated but even the most hardy sysadmin often forget : One should never log in directly as root. If your root user can be used to log in, its password can be brute forced. As root cannot be renamed, every Linux system (and many other operating systems) has a user named root. As such, it is an easy target for bots and hackers scanning IP addresses in search for poorly secured systems.

To disable root login from remote, ensure that the PermitRootLogin is set to “no” in the /etc/ssh/sshd_config configuration file.

Root account password & sudo

Disabling root login doesn’t prevent one from gaining root privileges using either su or sudo. Su leaves little other than the stock PAM policies to protect the root account. sudo on the other hand, is configurable and lets you restrict sudoer using groups and the commands that can be run using it.

Both approaches are totally viable and are hugely debated in the community. Sudo for example will give you the ability to let various users restart apache (which can be pretty useful if your apache process have instability problems).

You will find more about sudo in its manual (man sudoers), and its configuration file is pretty self-explicit (/etc/sudoers).


fail2ban-official-logoA quick and easy way to prevent brute force attack and denial-of-service attack, is to use Fail2Ban. Fail2Ban is a log watcher daemon which monitor for repetitive failure and then block the source IP using iptables. Most distributions bundles Fail2Ban with support for SSH already built-in, and it’s a matter of uncommenting the SSH part of the Fail2Ban configuration to enable it. I highly suggest you to visit the Fail2Ban Website and to dig in their how-to section. It is a powerful tool that can help you mitigate DoS attack on a lot of others services (like HTTP and FTP).

Restrict login only to SSH group member

Restricting who can connect to SSH will allow you to prevent unwanted or untrusted users of logging in. You should always enable this, even if all your users are remote ones. This will limit system accounts used by daemons, to be used to connect if they ever get hijacked.

Using the AllowGroups setting in the /etc/ssh/sshd_config configuration file, you can set what group can log in.

Disable password login


Passwords are the weakest part of the modern authentication scheme. If you have no requirements for password-based authentication, then use certificate-based authentication. It will prevent all kind of headache, like users locking themselves out by forgetting their password. However, you should remind your users that they are responsible of their certificate and have to keep them secure. Before doing this however, be sure to successfully authenticate using a certificate. You can follow this CentOS guide to do so.

To disable password authentication, change the PasswordAuthentication value to no in the /etc/ssh/sshd_config configuration file.

Minimal password complexity policy

PAM policy schema

Sometime, passwords are required. In that case, you should protect yourself from brute force attack. Most brute force attacks are dictionary-based and will usually focus on shorter, less complex passwords comprised of alpha-numeric characters. Unless you prevent your users from changing their password, you will have to implement PAM policies. PAM is highly configurable, but depends on your distribution. If you intend to change your PAM configuration, I’d refer to your distribution manual ( Here’s one for CentOS ). Ensure you have a way to recover your system in case you mess-up the PAM configurations files, as these modifications could lead to your system being unable to authenticate you.

Chroot user

As per Wikipedia, Chrooting “is an operation that changes the apparent root directory for the current running process and its children”. Doing so, the subprocess jails the user into that part of the file system. If a user account ever gets compromised, the attacker wont be able to access more than what the user was granted to.

Implementing a chroot is very specific to your environment and must be tailored to your need. I strongly advise you against following blindly a how-to but to instead invest into reading them and understanding the basics behind.


As you can see, security requires a lot of meticulous and detailed work. Turing a blind eye to small details can lead to server security holes. As such, knowledge is the best tool to keep your system secure. Know how to use your software and how to secure them correctly. Tighten and tune the bolt bit by bit. After a while you’ll be able to secure a system tightly and the small changes will become part of your daily habits.