Click here to Skip to main content
13,147,044 members (64,346 online)
Click here to Skip to main content
Add your own
alternative version


3 bookmarked
Posted 11 Feb 2011

Securing your SSH Server

, 11 Feb 2011
Any system administrator knows that securing their Cloud server is a top priority when setting up their web environment. There are many techniques out there so Rackspace Cloud Engineer covers his top techniques to provide as a guidance.

Editorial Note

This article is in the Product Showcase section for our sponsors at CodeProject. These articles are intended to provide you with information on products and services that we consider useful and of value to developers.

One of the most common questions that I see in my favorite IRC channel is: "How can I secure sshd on my server?" There's no single right answer, but most systems administrators combine multiple techniques to provide as much security as possible with the least inconvenience to the end user. For additional information on cloud, please visit

Here are my favorite techniques listed from most effective to least effective:

SSH key pairs

By disabling password-based authentication and requiring ssh key pairs, you reduce the chances of compromise via a brute force attack. This can also help you protect against weak account passwords since a valid private key is required to gain access to the server. However, a weak account password is still a big problem if you allow your users to use sudo.

If you're new to using ssh keys, there are many great guides that can walk you through the process.


Limiting the source IP addresses that can access your server on port 22 is simple and effective. However, if you travel on vacation often or your home IP address changes frequently, this may not be a convenient way to limit access. Acquiring a server with trusted access through your firewall would make this method easier to use, but you'd need to consider the security of that server as well.

The iptables rules would look something like this:

iptables -A INPUT -j ACCEPT -p tcp --dport 22 -s
iptables -A INPUT -j ACCEPT -p tcp --dport 22 -s
iptables -A INPUT -j DROP -p tcp --dport 22

Use a Non-Standard Port

I'm not a big fan of security through obscurity and it doesn't work well for ssh. If someone is simply scanning a subnet to find ssh daemons, you might not be seen the first time. However, if someone is targeting you specifically, changing the ssh port doesn't help at all. They'll find your ssh banner quickly and begin their attack.

If you prefer this method, simply adjust the Port configuration parameter in your sshd_config file.

Limit Users and Groups

If you have only certain users and groups who need ssh access to your server, setting user or group limits can help increase security. Consider a server which needs ssh access for developers and a manager. Adding this to to your sshd_config would allow only those users and groups to access your ssh daemon:

AllowGroups developers
AllowUsers jsmith pjohnson asamuels

Keep in mind that any users or groups not included in the sshd_config won't be able to access your ssh server.

TCP wrappers

While TCP wrappers are tried and true, I consider them to be a bit old-fashioned. I've found that many new systems administrators may not think of TCP wrappers when they diagnose server issues and this could possibly cause delays when adjustments need to be made later.

If you're ready to use TCP wrappers to limit ssh connections, check out Red Hat's extensive documentation.

fail2ban and denyhosts

For those systems administrators who want to take a bit more active stance on blocking brute force attacks, there's always fail2ban or denyhosts. Both fail2ban and denyhosts monitor your authentication logs for repeated failures, but denyhosts can only work with your ssh daemon. You can use fail2ban with other applications like web servers and FTP servers.

The only downside of using these applications is that if a valid user accidentally tries to authenticate unsuccessfully multiple times, they may be locked out for a period of time. This could be a big problem if you're in the middle of a server emergency.

A quick search on Google will give you instructions on fail2ban configuration as well as denyhosts configuration.

Port Knocking

Although port knocking is another tried and true method to prevent unauthorized access, it can be annoying to use unless you have users who are willing to jump through additional hoops. Port knocking involves a "knock" on an arbitrary port that then allows the ssh daemon to be exposed to the user who sent the original knock.

Linux Journal has a great article explaining how port knocking works and it provides some sample configurations as well.


The best way to secure your ssh daemon is to apply more than one of these methods to your servers. Weighing security versus convenience of access isn't an easy task and it will be different for every environment. Regardless of the method or methods you choose, ensure that the rest of your team is comfortable with the changes and capable of adapting to them efficiently.

Contact the Fanatical Support Team -


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Major Hayden
Canada Canada
My name is Major Hayden and I enjoy teaching others about system administration strategies almost as much as I enjoy learning them myself. I really hope you find this blog useful and your comments are always welcome

You may also be interested in...


Comments and Discussions

Generalyour posting is related with Linux only? Pin
Southmountain30-Jul-16 9:33
memberSouthmountain30-Jul-16 9:33 
GeneralMy vote of 5 Pin
Member 43208446-Jan-12 0:49
memberMember 43208446-Jan-12 0:49 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170915.1 | Last Updated 11 Feb 2011
Article Copyright 2011 by Major Hayden
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid