Demons Seeking Dæmons—A Practical Approach to Hardening Your OpenSSH Configuration
Listing 4. Changing the Port
# The strategy used for options in the default # sshd_config shipped with # OpenSSH is to specify options with their # default value where # possible, but leave them commented. # Uncommented options change a default value Port 13 Protocol 2
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.
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.
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 email@example.com.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Django Models and Migrations
- Hacking a Safe with Bash
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Home Automation with Raspberry Pi
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development