Bullet proof your server #2 - SSH

  • January 2, 2008
  • Avatar for peter
    Peter
    Upfold

See also: Part 1.

OpenSSH pufferfishWelcome 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

See you next time!

Avatar for peter Peter Upfold

Home » Articles »