See also: Part 1.
Welcome back! In the first part of this multi-part tutorial on FOSSwire, I look at some simple ways you can boost your security for the Apache web server. In this part, I’m going to look at securing the OpenSSH server, which is used for remotely logging in to your server.
OpenSSH is pretty secure as it is, but it never hurts to tweak a few settings here and there to make sure the most commonly exploited vectors are covered. So, without further ado, let’s jump in and look at what we can do.
1 - Disable SSH protocol 1
This one’s a very basic step and one that everyone should be doing. The SSH protocol, version 1, has known insecurities in it and can be a way for someone malicious to get into your server.
There’s almost zero reasons why you need to keep allowing the use of protocol 1 on your server nowadays, so disable it.
You’ll need to open up your /etc/ssh/sshd_config file in your text editor of choice, and search for the line beginning with Protocol (although it’s normally near the top).
The Protocol line should read:
Protocol 2
That means - accept version 2 of the protocol, and nothing else. Save your config file and restart sshd.
2 - Enable key-based logins
Logging in with a password is all well and good, but you can get better security by using a private and public key pair. I’ve covered how to generate your key in a previous tutorial, so read up on that here.
To enable key-based logins on the server, make sure these directives are set in the configuration file:
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
Once that’s done, you need to copy your key to the server.
3 - Don’t enable password-based logins
Further from setting up key-based authentication, you can go the next step, which is to allow only key-based logins. By disabling all password logins, no-one can remotely attempt a brute force attack against any account passwords on your system. The downside is that all users that need to log in need to have a key set up and working properly.
If you’re ready to take this step, make sure you can log in with a key properly (so you don’t lock yourself out), then set this directive in sshd_config:
PasswordAuthentication no
Save and restart sshd, and anyone without a key gets thrown straight back out.
4 - Don’t run on port 22
The default port for SSH is 22. Everyone knows this, which is a bad thing. The potential attacker will go out, and probe as many machines as they can find, to see if port 22 is open. If it is, they’ll start knocking.
Even if they don’t get in, you can save yourself the hassle, by moving to a non-standard port. Pick a number above 1024, and use that as your port number in the config file. For example, if I want port 1617, I would put:
Port 1617
Now, I just need to remember when connecting to specify the port in what ever software you’re using to connect. For SSH’s command line client, for example, like so:
ssh -p 1617 myserver
5 - No remote root logins
This one is pretty much common sense. Don’t let root log in via SSH. That doesn’t mean you can’t get root privileges remotely, as it’s easy enough to set up a user with permissions to use su or sudo.
Almost every Unix system has the superuser called root, so attackers will use this as a username they know exists on your system, and try to brute force the password.
To deny root logins, set this directive in your sshd_config:
PermitRootLogin no
Like this article? Subscribe to FOSSwire now (
fsdaily.com wrote:
Story added…
Your story has been submitted to fsdaily.com! Come and promote your article by voting for it here on FSDaily! Let your readers know they can vote for your story too….
# Posted on 03-Jan-08 at 7:57 am
duh wrote:
Maybe you should add a cmd to restart the sshd deamon ?
# Posted on 03-Jan-08 at 8:08 am
Rada wrote:
Moving your sshd to a different port is security through obscurity, and if you’re even going to do it (Even though it’s a stupid non-solution, as opposed to banning the IP altogether if it tries to login more than a certain amount of times) you should be very aware that you are *not* more secure.
Besides, the doorknocker problem is solved entirely by disabling passworded logins and using key-based authentication.
If key-based authentication is not a feasible solution to your server, you should install a service like DenyHosts or similar.
For more discussion about DenyHosts see http://nixy.dk/2007/10/22/using-daemontools-supervise-on-freebsd/
# Posted on 03-Jan-08 at 8:37 am
Rada wrote:
Whoops, sorry. The link was http://nixy.dk/2007/10/12/denyhosts-on-freebsd-62/
# Posted on 03-Jan-08 at 8:38 am
Eike Herzbach wrote:
If you want to make that port default for your client and avoid disconnects:
$ cat ~/.ssh/config
ServerAliveInterval 7
TCPKeepAlive yes
Port 1617
# Posted on 03-Jan-08 at 8:39 am
Jeroen wrote:
Security through obscurity is NOT security. It’s foolish to believe that this is even slightly more secure than using the standard port 22.
If you’re afraid of brute-force, a daemon like Fail2ban is pretty decent at solving that for you.
# Posted on 03-Jan-08 at 8:48 am
Jeffrey S wrote:
Don’t forget DenyHosts. It can easily pick up on multiple failed-password attempts and automagically add the attackers to hosts.deny. It’s one of the first packages I emerge on a new box.
# Posted on 03-Jan-08 at 8:48 am
Elijah wrote:
Great post, the port change is a good suggestion.
# Posted on 03-Jan-08 at 8:48 am
Noah Everett wrote:
Great tutorial. Thanks.
# Posted on 03-Jan-08 at 8:48 am
MonkeyC wrote:
To the No-Security-Through-Obscurity flag-wavers.
Will you please acknowledge that obfuscation lowers the number of *attempts* made on the port to crack a system? And that the time between discovering an 0-day in the wild and patching the system is not finite, but it is short? So dodging hack scripting against port 22 isn’t a complete lost cause, it’s just not the entire onion either.
Sheesh.
# Posted on 03-Jan-08 at 8:59 am
Dave wrote:
Although changing port from 22 to another one isn’t a safeguard against people hacking into it, it does add another layer of obscurity that may foil someone trying to break in.
That, in combination with the other measures, is a good way to increase your SSH security.
But, don’t forget to tell someone who you may have working on your server that the port has changed, because it certainly adds to confusion!
# Posted on 03-Jan-08 at 9:12 am
Mace Moneta wrote:
Changing the port does improve security - by making it 65535 times more annoying to find the SSH port. With a proper firewall configuration slowing the process, that can add days to an attack before the first login attempt. Sometimes security by obscurity is useful as an additional tool - not the exclusive tool - providing protection.
The downside to using a different port is that some services (e.g., web blogging sites) that support SSH do not support arbitrary ports (or key login, for that matter).
Probably the two most useful items are disabling protocol 1, and not permitting root logins. As others have mentioned, a secondary system that blocks repeated failed attempts in the firewall is also useful, though you’ll need to deal with false positives as a result of forgetful users.
# Posted on 03-Jan-08 at 9:13 am
Randall wrote:
Fail2Ban is an alternative to DenyHosts, written in python. It can temporarily ban IPs for failed SSH and FTP logins, Apache auth failures, etc.
http://www.fail2ban.org
# Posted on 03-Jan-08 at 9:14 am
MonkeyC wrote:
Jeroen,
Oh perfect. Bash adding hurdles to dodge poorly made scripts, then suggest adding more layers, like Fail2Ban, which add MORE vulnerabilities.
http://www.ossec.net/en/attacking-loganalysis.html
So now someone can manipulate my firewall by injecting crafted failed login attempt text.
# Posted on 03-Jan-08 at 9:17 am
Wesley Workman wrote:
Just to add what Randall said, Fail2Ban is a very easy and quick addition that adds a large amount of security. It works by reading your ssh logs and using IPTables. Tt enables you to ban a given number of failed attempts for a given duration. Extremely helpful in preventing brute force.
# Posted on 03-Jan-08 at 9:21 am
Internet_pixie wrote:
Gahh! OK fine. Key-based authentication *is* more secure than password-based. But if people follow your article they will find it an uber hassle! Every time they want to login they will have to type in their “secure but stupidly long” passphrase.
If the article is going to promote the use of keys it should also explain how to use ssh-agent or helper scripts like keychain.
# Posted on 03-Jan-08 at 9:25 am
Brandon wrote:
Actually you don’t need complicated things like DenyHosts or Fail2Ban to ratelimit failed login attempts on ssh. The problem can be solved at the iptables level in Linux using the hashlimit module.
Here’s an example, where “NEW_TCP” is my table for incoming semi-legit TCP SYN traffic (already filtered for funny portscanner flag combos and so-on), and “BADGUYS” is my destination table for probable attack traffic (rate-limited logging + DROP):
# Send incoming port 22 ssh connections to LIMIT_SSH
iptables -A NEW_TCP -p tcp –dport 22 -j LIMIT_SSH
# Ratelimit incoming ssh connections per source IP to no more than a 2/minute average, with a burst of 3. Read the ipt_hashlimit docs for details on all of the tunables:
iptables -N LIMIT_SSH
iptables -A LIMIT_SSH -m hashlimit –hashlimit-name sshrate –hashlimit-mode srcip –hashlimit 2/min –hashlimit-burst 3 –hashlimit-htable-size 20 –hashlimit-htable-max 30 –hashlimit-htable-expire=300000 –hashlimit-htable-gc 60000 -j ACCEPT
iptables -A LIMIT_SSH -j BADGUYS
# Posted on 03-Jan-08 at 9:51 am
Redhat Rocky wrote:
I recommend using:
PermitRootLogin without-password
which disables root ssh logins via password as opposed to what one would expect it to do.
Setup root with a separate ssh-key for those emergency situations (like say, a forgotten root password!).
# Posted on 03-Jan-08 at 10:09 am
Tom Burton wrote:
Wow, saw this on Digg. I myself have just started playing with key-based logins, and I have to say they are pretty useful, especially for scripting.
You’re tips are good, some of them are integrated into a program I’ve written for Ubuntu/Debian: ProShield.
It does other things, like making sure you are up to date. Check it out http://proshield.sourceforge.net
# Posted on 03-Jan-08 at 10:10 am
James Coletti wrote:
Just a note to Debian (and possibly other distros) users. I believe just setting “PasswordAuthentication” to “no” will not disable password logins entirely. If through testing you realize you can still log in to your system with a password and without a key, try disabling PAM by adding “UsePAM no” to your sshd config.
# Posted on 03-Jan-08 at 10:15 am
Derek Anderson wrote:
+1 MonkeyC
Adding an automated ban function is one of the worst mistakes an admin can make. Think about it; you are giving remote attackers with the ability to spoof packets the additional ability to LOCK YOU OUT! This is ludicrous! Worse, they can ban ARBITRARY hosts. What happens when these people start spoofing attack packets from your DNS server, your web proxy, or your up2date repo?
Kaminsky poked a lot of holes in this during one of his DNS talks years ago. Do you really want remote users to be able to modify your firewall rules?
# Posted on 03-Jan-08 at 10:29 am
Ben wrote:
Umm.. Unless your distro is living in the dark ages. Key authentification is enabled by defaults. All the # out items in the sshd_config should be the “defaults” that are compiled into the ssh deamon. Or they are when you use the openssh right from portable.
- Ben
# Posted on 03-Jan-08 at 10:46 am
Ben wrote:
Oh FYI on the moving ports (something I don’t subscribe to, but I frankly don’t care anymore), please do yourself a favor and pick a port BELOW 1024!!!! Anything above that can be used by a normal user, and thus can open you up to other issues if your deamon were to “magically” drop offline.
# Posted on 03-Jan-08 at 10:51 am
Mahmoud wrote:
I do not think that fail2ban would work when key authentication is the only method used. Moreover, Brute force attacks are not useful against key authentication.
Obscurity adds a layer of security, although you can not depend on it but I think it is worth using.
1. Changing port
2. listening on a different IP, other than the one used for web services.
# Posted on 03-Jan-08 at 10:56 am
Johann wrote:
Changing the port might thwart some script kiddies but it does not secure the server 65535 times as someone suggested. All it takes is one port scanner run to the server to find out what the SSH port is.
I personally don’t see a need to change the port number; IMO the inconvenience outweighs the security gain from the tweak.
Better measures would be TCPWrapper and use of public/private keys, which makes it almost impossible to break into.
# Posted on 03-Jan-08 at 11:35 am
name wrote:
you should mention the use of the “AllowUsers” directive. Accounts should only have access specifically turned on; otherwise, test accounts and/or system accounts could potentially be breached.
Also, you should mention running the latest version of whatever SSH daemon you happen to use. New vulnerabilities and side-channel attacks get updated/patched often.
# Posted on 03-Jan-08 at 12:14 pm
Catsby wrote:
Wow, I can’t believe no one has mentioned the first (and to me, most important) rule that I add to all my SSH installations, if possible:
AllowUsers johndoe janedoe
By allowing just a few users, a “deny first, then allow” security policy is set. This eliminates the uncertainty of locking down every system account. I’ve found that the most effective security measures are to deny everything by default, and then only poke holes for known allowances. This is just like how you shouldn’t try to set up IPTables by individually blocking every unwanted port - you simply allow the few you want, and then block the rest by default.
Most of the security problems I’ve experienced regarding SSH have been successful brute-force login attempts to ancient client accounts that no one has remembered to disable.
# Posted on 03-Jan-08 at 12:26 pm
or4n wrote:
Why would you even keep SSH port open 24/7? Just use knock daemon so you can open SSH port to your IP for say 30 seconds so you can log in and then close it again
If you have stateful firewall (like iptables), it won’t close your already open SSH-session.
Here you can find more info about
http://www.portknocking.org/
This way you can keep your password based login and still be secured
# Posted on 03-Jan-08 at 1:37 pm
Mark wrote:
Yeah, moving the port number for SSH does make it slightly more secure, but with the proper security practices in place (password complexity, brute force detection), the difference is negligible at best, and it can be a big hassle for your users. But I guess if you are paranoid…
# Posted on 03-Jan-08 at 3:22 pm
CCNA Discovery wrote:
These were some interesting tips. Everyone needs to be aware of these holes instead of blindly reading instructions and running their servers.
# Posted on 03-Jan-08 at 4:46 pm
Dude wrote:
Also look into
AllowUsers
AllowGroups
DenyUsers
DenyGroups
So that you can control where people can come from for which account and group.
# Posted on 03-Jan-08 at 5:07 pm
Bryan wrote:
Gah! I have heard that argument over and over again about changing ssh to a non-standard port.
“security through obscurity is no security at all” Says the broken record.
I believe heavily in security metrics because numbers are awfully hard to argue with.
In a university environment a machine with ssh on port 22 in my DMZ would receive an average of ~100 invalid login attempts per day (averaged over the course of 2 months).
This same machine in the same DMZ running SSH on port 51234 received an average of zero… no, not a average of zero… just zero.
This effectively eliminates all scripted attacks, worms, Trojans, bots and most uninitiated real attackers.
In fact if you run it on a very high port — say 51234 — most people won’t even find it with a port scanner.
One would have to statically define the port range as most port scanners quit far before 51234.
At that rate scanning ports 1-51234 would take an insane amount of time per host, and most attackers scan huge blocks of hosts.
At that point hopefully an IDS/IPS would pick up the port scan and make the whole thing moot.
Seriously. Its not a fool proof security measure and I certainly wouldn’t use it as the only means of protecting SSH, but its an effective layer. And those same people that are so quick to spew out the “Security through obscurity” cliche are also the same that are quick to pull out the “Layered Security” ones.
# Posted on 03-Jan-08 at 5:20 pm
AlbanyWiFi.com » Blog Archive » Bullet proof your server #2 - SSH wrote:
[…] Link here. […]
# Posted on 03-Jan-08 at 6:21 pm
links for 2008-01-04 « Mandarine wrote:
[…] Bullet proof your server #2 - SSH Disable SSH protocol 1, Enable key-based logins, Don’t enable password-based logins, Don’t run on port 22, No remote root logins. (tags: tutorial server security opensource) […]
# Posted on 03-Jan-08 at 9:26 pm
tecosystems » links for 2008-01-04 wrote:
[…] FOSSwire » Bullet proof your server #2 - SSH hadn’t known about ’ssh-copy-id’ - cool stuff (tags: ssh security linux howto sysadmin) […]
# Posted on 03-Jan-08 at 10:25 pm
Johann wrote:
Bryan,
Changing SSH port works well if you have few servers to manage. When you manager large number of servers, you end up having to maintain server-to-SSH-port list, which in my opinion is a pain.
You could, of course, use a common high-port for SSH across all servers. But then, it kinda defeats the point of shifting to high-port anyway because once attacker finds out your SSH port, then he can attack your other servers with the same port.
In my opinion the most secure protection is the TCPWrapper combined with key-base authentication. This makes it very difficult for attackers to gain access to the server, even if they know that the port 22 is alive.
# Posted on 03-Jan-08 at 10:37 pm
Bulletproof ssh « 0ddn1x: tricks with *nix wrote:
[…] Bulletproof ssh Filed under: BSD, Linux, OSX, Security — 0ddn1x @ 2008-01-06 17:22:57 +0000 http://fosswire.com/2008/01/02/bullet-proof-your-server-2-ssh/ […]
# Posted on 06-Jan-08 at 10:23 am
» SSH on a Non Standard Port downgrade.org: The rantings and insight of a 20 something ethical hacker, coder and IT samurai. wrote:
[…] recently posted a comment on FOSSwire.com in response to other comments condeming the author for suggesting moving ssh to a port besides 22 […]
# Posted on 07-Jan-08 at 6:38 am
Asegurar y respaldar un servidor web « Jorge Software Libre wrote:
[…] Bullet proof your server #2 - SSH […]
# Posted on 07-Jan-08 at 10:05 am
Linux: Securing openSSH | Hackosis wrote:
[…] from FOSSwire wrote up a nice tutorial on securing SSH in 5 simple steps and covers the […]
# Posted on 10-Jan-08 at 8:15 am
Secure Linux/Unix system that runs OpenSSH service | Linux Screw wrote:
[…] most common and safe method to access remote Linux or Unix system. The article is freely available here. Share This Related posts:Local and remote X sessions on different consolesSecure shell (ssh) […]
# Posted on 10-Jan-08 at 4:11 pm
i621148 wrote:
/etc/hosts.deny
ALL : ALL \
: severity auth.info \
: twist /bin/echo “You are not welcome to use %d from %h…”
/etc/hosts.allow
#
# hosts.allow This file describes the names of the hosts which are
# allowed to use the local INET services, as decided
# by the ‘/usr/sbin/tcpd’ server.
#
# Prevent those with no reverse DNS from connecting.
ALL : PARANOID : RFC931 20 : deny
# Allow anything from localhost. Note that an IP address (not a host
# name) *MUST* be specified for portmap(8).
ALL : 127.0.0.1 : allow
ALL : 192.168.1.200 : allow
ALL : 192.168.1.201 : allow
ALL : 192.168.1.202 : allow
ALL : 192.168.1.203 : allow
ALL : 192.168.1.204 : allow
ALL : 192.168.1.205 : allow
# allow ssh from anywhere
# uncomment the line below if you are going on a trip
# sshd: ALL
# me @ work
ALL : 207.68.183.120 : allow
# You need to be clever with finger; do _not_ backfinger!! You can easily
# start a “finger war”.
fingerd : ALL \
: spawn (echo Finger. | \
/usr/bin/mail -s “tcpd\: %u@%h[%a] fingered me!” root) & \
: deny
# Posted on 11-Jan-08 at 8:05 pm
i621148 wrote:
these files above have pretty much stopped all brute
force attacks appearing in my logs…
# Posted on 11-Jan-08 at 8:07 pm
Chris wrote:
Here is what I used to do.
1 - change port (it does make things a bit better stops automated trojan scanners who scan entire ranges on port 22 and keeps my security log clean, if I see brute attempts on a non standard port I know its probably someone who ‘really’ wants to get in) Inconveniance is certianly less then training users to all use keys.
2 - disable password auth but leave keyboard interactive on.
3 - limit who can login, I typically allow ssh group in, so a default deny as someone said.
4 - disable tcpkeepalive and use encrypted keepalive instead.
5 - set MaxStartups to an appropiate setting to make it harder to brute force, likewise with LoginGraceTime and MaxAuthTries.
I then decided to allow direct root login but only with my key not via passwords, the problem is the no password setting does not disable keyboard interactive so I have changed keyboard interactive back to normal password auth and have the no password on root, which is useful if for whatever reason you are prevented from logging in to your normal account and been able to su to root.
I have used denyhosts in the past but as someone else also said it itself is a potential dos tool against your own server as someone can spoof your ip or even your gateway ip effectively locking you out your own machine.
Lets face it also if you leave the port on 22 you will typically get at least a dozen or so login attempts each day and you would then develop a habit t not investigate these logins as they would be considered routine meaning a human brute forcer is likely to be unoticed whilst a different port your routine will be brute force attacks so when a humen tries to brute force it will be much easily noticeable, combined with the downsides I stated about using tools like denyhosts I can only reccomend changing ssh port.
# Posted on 12-Jan-08 at 11:14 pm
» links for 2008-01-15 It tastes like burning: Ramblings from someone who really doesn’t have much to say wrote:
[…] FOSSwire » Bullet proof your server #2 - SSH (tags: security ssh server howto tutorial admin administration linux sysadmin) […]
# Posted on 15-Jan-08 at 3:17 pm
it’s about time» Blog Archive » links for 2008-01-23 wrote:
[…] FOSSwire » Bullet proof your server #2 - SSH SSH, one of my favourite tools in the timelady arsenal:) (tags: ssh security sysadmin tutorial linux nas network networking reference server shell administration hack howto configuration system tools) […]
# Posted on 23-Jan-08 at 4:26 pm
Linux server security - Overclock.net - Overclocking.net wrote:
[…] bookmarks I cam across these two… sorta similar http://www.howtoforge.com/ssh-best-practices http://fosswire.com/2008/01/02/bulle…-server-2-ssh/ Which could fall under the prevention category. Obviously you can write first and foremost about […]
# Posted on 11-Feb-08 at 11:22 pm
xUx wrote:
You should give a try to http://lmf.sf.net , it’s a great tool which can be used for brute force attacks and such. I personally use it to monitor sendmail, ssh, ftp activity and block those unwanted connections.
My 2 cents, good article + comments
# Posted on 14-Feb-08 at 9:08 am
foo wrote:
Or, if you’re not using Linux, you can use OpenBSDs beautiful PF to handle brute force attacks. Your /etc/pf.conf should contain something like:
table persist
block in quick from
pass in on $ext_if inet proto tcp from any to any port ssh keep state (max-src-conn 5, max-scr-conn-rate 8/10, overload flush global)
You might want to add yourself to a pass in quick before the block in quick from , in case you should get yourself added to that list.
pass in quick on $ext_if inet proto tcp from $trusted to any port ssh
# Posted on 17-Mar-08 at 8:43 am
PSTAM.com: Behind the Scenes - PaulStamatiou.com wrote:
[…] a long name like mine, it saves quite a bit of time in the long run. It’s also a good idea to disable root login via SSH and enable key-based SSH authentication for […]
# Posted on 30-Mar-08 at 4:29 am
Secure your SSH server « Now I Remember wrote:
[…] Part of the text was taken from FOSSWIRE […]
# Posted on 13-May-08 at 9:21 pm