Demons Seeking Dæmons—A Practical Approach to Hardening Your OpenSSH Configuration

A few simple configuration tweaks could save you sleepless nights over whether or not someone might crack your SSH server.

Given even the slowest typist on the planet, what would be the expected time to allow them to enter a password? Assuming an eight-character password, would it be eight seconds? Give them two seconds a character, and they have a hearty 16 seconds. Allow them 20 seconds of network latency, and we are at just more than 30 seconds, which seems like a more than generous amount of grace time. This is often surpassed with the default sshd configuration, though with the LoginGraceTime sometimes set as high as 120 seconds. This is the maximum amount of time that the server allows for a successful login. Ask yourself, if one were to knock on your house door and you were behind it, what would the maximum amount of time for deciding whether to let this person or people in? Coupled with this, we have another unique login directive named MaxStartups. This MaxStartups directive can be a very powerful deterrent when fighting the SSH scanners. MaxStartups specifies the maximum number of concurrent unauthenticated connections to the SSH dæmon. Note that this means unauthenticated connections. Therefore, if a script were running, trying to brute-force its way into the machine, and the script was able to fork processes, it could launch multiple (maybe even hundreds) of login attempts almost simultaneously. A good rule of thumb is to use one-third the number of your total remote users with a maximum setting of 10.

Initiating the Changes

There is little to be considered to implement the changes mentioned. The default configuration is merely a guide, and it is the administrator's responsibility to expand on the guide and harden the sshd configuration. Prior to making the changes, it is highly recommended that you temporarily start sshd on an alternate port to provide yourself with a back door should you misconfigure the primary sshd and lose the connection. When issuing a restart on sshd, it is possible to make a mistake in the configuration file, which will result in the dæmon failing to restart (if it is first stopped). Doing ssh -p <alternate port> will allow a second dæmon to run and provide you with a secondary secure connection should the first one fail due to a configuration error. We are after all, working remotely, and if we lose the SSH dæmon without an alternate, physical access to the console will be required to make further modifications. Even though it may seem obvious, it is worth mentioning that you must issue a SIGHUP or restart the SSH dæmon for any changes to take place. To expand further on the idea of a second port being opened, it is possible to add a startup script for a second sshd to run with an alternate sshd_config file that specifies no options other than a single-user account from a single source. This essentially allows you to guarantee yourself access from a (presumed) secure machine if the initial dæmon is ever shut down.

Summarizing the Chase

For Linux systems administrators, it really comes down to you or a group of people against the world. You are on one end, providing access to your machine, and on the other end is a world of network-connected people, many of whom would like to have access to your machine. Usually the tools that are used to exploit the SSH dæmon are built with the default configurations in mind. It is the low-hanging fruit that is often the target, and it is your job to know your local environment and needs to remove that low-hanging fruit before it gets picked by others. A compromised machine causes not only havoc within your environment, it also presents a risk for the other multimillion or billion computers connected worldwide. OpenSSH provides an outstanding tool for remote access. Comparing the tool to a crescent wrench is a fair analysis. Both the wrench and OpenSSH are delivered with a wide range of capabilities. Just as you will need to adjust a crescent wrench to make the most of it, adjusting the default configuration of OpenSSH will maximize your remote-access capabilities while also providing a more secure environment.

Phil Moses spends his days managing Linux systems for the Physical Oceanography Research Division at Scripps Institution of Oceanography and spends his time off contemplating access to those remote areas of the world that are less traveled. Phil can be reached at philmoses@cox.net.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

ssh work

Steve Jim1's picture

The new work about ssh server is to be access very carefully to get fixed.

ssh -p <alternate port>

Keith Daniels's picture
Doing ssh -p will allow a second dæmon to run and provide you with a secondary secure connection Shouldn't that be: sshd -p ?

All the new OSs and windowing systems are oriented towards content consumption instead of content production.

--Steve Daniels 2013

Denyhosts

Anonymous's picture

"DenyHosts is a python program that automatically blocks ssh attacks by adding entries to /etc/hosts.deny. DenyHosts will also inform Linux administrators about offending hosts, attacked users and suspicious logins." Very nifty when your machine is getting hammered with brute force attacks. You can find it here.

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix