I have written a bit about some of the uses for ssh (here and here). I thought I would outline a few quick tips on securing an ssh host machine. One of the biggest security problems and security log notices that I find are automated connection attempts via the ssh port of a machine. Based on this there are a few things that I suggest in helping secure your ssh port and your machine security.
One of the first steps to increasing the security of your machine is to change the default port for ssh. This can be done by editing the /etc/ssh/sshd_config file.
sudo vim /etc/ssh/sshd_config
Look for the line that defines the port. By default it should look like “Port 22”, generally found near the top of the file. You’ll want to change this to a more random port. While the new port can be found, it is a good measure to change it to something more customized. I suggest something above 20,000. Your new line entry would look like “Port 22255” or “Port 22002”, etc.
The next level of ssh security is allowing or disallowing login by the root user. Remember, the root account is not activated by default on an Ubuntu machine but if it has been activated the simplest and easiest way to gain access would be to connect via ssh as the root user. To disallow login access as the root user you’ll want to search for the line “PermitRootLogin yes” and change it to “PermitRootLogin no”.
There are quite a few more things that you can configure for additional levels of security. The last that I’d like to outline here is the AllowUsers setting. From the man page:
This keyword can be followed by a list of user name patterns, separated by spaces. If specified, login is allowed only for user names that match one of the patterns. ‘*’ and ‘?’ can be used as wildcards in the patterns. Only user names are valid; a numerical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER@HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts.
In other words you could add a new line to your sshd_config to the extent of “AllowUsers username” to limit connections to just yourself or “AllowUsers [email protected]” to only allow your username from your work or office domain.
Lastly, for any of your changes to take effect you’ll need to restart the sshd service. This can be done with the command below:
sudo /etc/init.d/ssh restart
Between the three of these options you should have a pretty tightened down machine when it comes to ssh. Alternate ports, disallowed root login and restriction to specific usernames and domains. This’ll give those script-kiddie crackers a headache! If you have any other suggestions on added security for ssh please leave a comment.
Perhaps on your firewall only allowing certain IPs to connect to the ssh port.
Although that is not really securigin ssh as it is using a firewall.
Their is also a section in sshd_config about ssh protocol and I believe it should be set to version 2 only…?
Bah! That’s mostly security by obscurity, and pretty ineffective, but changing ports can make wonders for cleaning up your logs. A much more useful improvement is OTP, by the means of pam_opie. With OTP one can use an untrusted machine (e.g. one in work) to login to his host.
Changing the port might work most of the time, but not if you have a server, where many people would like to log in, e.g. ssh gateway. Telling all those people how to use a different port in their favorite client is in pain (in certain mostly dark places).
I case people are worried about their logs, I’d suggest the package fail2ban: trying to log in from the same IP for more than n times in a minute results in a blacklisted IP for some time, really helpful against ssh-scans 🙂
Your idea of putting ssh on a different port is useless. Proof is right here:
nmap -sV -p 1-60000 yourhost
Since the root password is locked on a default ubuntu install, changing the PermitRootLogin directive is redundant, but still a smart move.
Also, how can you write a guide on securing ssh when you don’t mention key based authentication at all? A weak key is 1024 bits whereas a strong one is 4096 bits. Remembering a 1024 bit password is impossible while remembering a password to decrypt your 1024 bit key is not.
You don’t mention making sshd accept protocol version 2 only, but I believe that the Ubuntu ships uses Protocol 2 by default. You might mention that however because ssh works on more than just ubuntu. SSH protocol version 1 is suceptible to man in the middle attacks which allow hackers to hijack your session!
So now that I (as a hacker) have found your server using nmap, what will I do? Well brute force it for days until I crack a password of course. To prevent that from happening, take a look at an ubuntu package called fail2ban. It is quite brilliant and will block people trying to brute force your ssh passwords. Also note that if you used key based authentication, brute forcing is impossible.
Keep up the good work though, this is a good start.
Changing the port for sshd doesn’t give you any real security benefit at all. Port scanning will easily reveal what ports your computer has left open and which not.
Programs like Bounce-O-Matic are much better at mitigating automated ssh login attacks by dynamically adjusting firewall rulesets to block off those computers performing the attack temporarily.
Not permitting root logins is a good measure, but once an attacker has gained access to a user account on a box, getting root access becomes an easy matter anyway, either by doing a simple su/sudo attack or, in case su/sudo has been disable, trying to exploit security holes in locally installed software.
AllowUsers is a good policy to use, but again, IP adresses can be spoofed and brute-force attacks can reveal the names of user accounts still permitted to log in.
The best way of securing an ssh server is to use public-key authentication instead of password-based login. This makes brute-force attacks virtually impossible and makes things like AllowUser and disabling root logins less necessary, as well.
Yet another great post. I just want to thank you for your blog. Almost every single post has valuable information. Keep them coming :).
All the best,
Daniel.
This DOES NOT INCREASE SECURITY.
All it does is get rid of the annoying messages caused by scanners on port 22 in your logs.
If you want security, make sure to have good passwords or not allow password logins at all.
If you want to get rid of scanners, I recommend using the RECENT match of iptables.
I’ve used a great program called Denyhosts which can block brute force attempts after a certain number of bad logins.
http://denyhosts.sourceforge.net/
Some of your suggestions — not allowing root logins, for instance — are good ones, and in fact they’re implemented by default in many OpenSSH distributions.
Changing the port, by contrast, does nothing to increase security. As someone already pointed out, an attacker can very quickly find SSH on whatever port you’re using with nmap -sV.
I do recommend eliminating password authentication for SSH. If you need to secure a machine and allow SSH access, require public key authentication. You may also want to run some system like DenyHosts to block access after some number of failed login attempts. (DenyHosts works by adding the offending IP address to /etc/hosts.deny. I prefer to add it to a “banned” table in pf, but either method can be effective.)
(with my correct website this time)
Someone on planet Debian wrote a response to this post that is very noteworthy…
http://blog.drinsama.de/erich/en/linux/2007021502-false-sense-of-security
Couldn’t agree with it more.
It is sad to see that so many people here do not recognize that changing the default port on your SSH server DOES increase security. Let’s take a walk down Reality Lane, shall we?
First, check the logs. Nothing is more informative. Keeping SSH on the default port allows script kiddies across the planet chances to control your box. As such, everything is in the logs.
Second, recognize that 99% of attacks on SSH are automated. There is no human pilot behind these attacks. They are scripts running on zombie machines. And, these attacks are looking at the default port for SSH. Nothing more.
Third, realize that changing your port GREATLY REDUCES the attacks. Check the logs for verification after the change. Notice a difference? It’s because the attacks are no longer effective, as they are still working on your de
As such, even though crackers have tools to scan ports, and find the port you are using for SSH access, the fact of the matter is, it’s just not happening. As such, you have just increased the security of your server my moving the port number.
It’s not a false sense of security at all. Sit on port 22, and take the attacks, or move the port, and reduce the number of attacks 99.99%. The ball is in your court.
Aaron is exactly right.
In the real world, you will almost never get scanned on every port. Which would you rather do as an attacker, scan 65000 machines on port 22, or scan one host on 65000 ports?
If your goal is top stop annoying brute force scans and 0day attacks, changing the ssh port is the single most effective thing you could do. If your goal is to stop specific directed attacks, then you sure as hell should be employing EVERY single method you can think of.
Disabling password auth and some other methods aren’t going to help you if there is a 0day vulnerability. Changing the port will.
Personally, I only allow ssh conections from trusted networks. When that isn’t possible, I run ssh on a random port.
All of this is good — I think the port is sort of not necessary. Obscurity is never really something you should rely on first hand. It makes it unpractical.
Now, what I am surprised wasn’t mentioned in the article was… don’t use password logins? But Passphrase protected RSA public keys! Carry them with you on your USB stick if you must, too.
Pingback: Data Access Notes » What You Ought To Know About Securing SSH
DenyHosts is a nice program that blocks IPs (add to hosts.deny) when # of login attempts occur. I enabled the PermitRootLogin because it makes my life easier!
I use fail2ban with iptables and also change ports from defaults.
There are plenty of people suggesting using RSA keys instead of passwords, but can someone explain how to do this? I've got the keys created, but I can't figure out how to dissable password logins without affecting local logins.
It would be really nice to be able to validate the remote MAC address as well. It's just a shame that information is only transmitted on a local network. 🙁
@ Aaron and @ Justin get it. Changing the port is like moving from downtown into the country. Sure if one person was out to get you they could follow you – but the rest of the city won’t bother to chase you all the way out there.