Securing a Linux Server: SSH and Brute-Force Attacks

If you have a web server, then you are the target of many possible attacks. *ANY* port you have open on that server can be exploited, so you if you value your uptime and your data, you need to secure it. This article focuses on locking down your SSH configuration and user permissions.

If you’ve had your server online for a while without locking down your SSH configuration, have a look at this file: /var/log/secure and see if you’ve got a lot of connection attempts.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

And now you get something like this output:

Your identification has been saved in /Users/youruser/.ssh/test.
Your public key has been saved in /Users/youruser/.ssh/test.pub.
The key fingerprint is:
12:34:56:78:01:23:ab:a7:42:2b:46:5a:3f:fc:4c:ca youruser@ComputerName
The key's randomart image is:

Back on your Web Server

Now that you’ve created your public and private key on your desktop machine, you need to head over to your web server and make some changes.

1. Log into your web server and create users

If you are still logging in as the root user, you need to create other users:

Create a user:adduser your_usernameCreate a password for the user:passwd your_username

Test logging in as this user now. From your desktop machine, tryssh your_username@your_webserver.com

2. Give One User Sudo Privileges

Now that you have a user other than the root user, you should lock down the root user and push root privileges to the sudo command. The goal here will to disable root logins entirely.

You will need to switch to the root account to perform the following. You can either login as the root account from your desktop machine, or switch to the root account by using the Switch User command (su):[prompt]$su - root

You grant sudo privileges to your users by editing the sudoers file… but you can’t simply edit that file. You must use the visudo command. This is a very special variant of the VI text editor which is designed for a single purpose: to edit the sudoers file. The security of your entire server can be compromised by this single file, so the visudo command ensures that any editing of this file never allows it to be in a state where its permissions could be compromised.

Other than that, the visudo program works like the VI program — it’s a text editor, but you should familiarize yourself with the editor before messing with your sudoers file.

WARNING: You can lockout ALL users from your machine if your fat fingers or VI ignorance corrupt this file!!! If you are at all unsure of your VI abilities, please review our article: VI Overview.

The goal in editing this file is the addition of a single line of text:your_poweruser_name ALL=(ALL) ALL

There are a lot of other custom modifications you can make to this file to allow certain users access to individual functions, but that’s a more advanced topic.

Save the file, but DO NOT CLOSE THIS WINDOW. If you made a mistake, you need access to this file in order to fix it. I recommend leaving this window open until you’ve got EVERYTHING locked down and you’ve verified that it works.

Again, go back to your desktop machine and test that you can still login using a password. Once you’re in, try using the sudo command and make sure that you an use it to execute commands.

Add Your Public Key to the Web Server

In a new window, login to your web server from your desktop machine. You should still be prompted for your password.

See if you’ve already got a .ssh directory in your user’s home directory:[prompt]$ ls -Gal

If you don’t have it, create it:[prompt]$ mkdir .ssh

Now, move into that directory:[prompt]$ cd .ssh

If you don’t already have a file named authorized_keys, you need to create it (again, you can use the VI text editor)

You need to paste your entire public key from your desktop machine into this file on the web server. IT MUST FIT ON ONE LINE. SSH expects each key to occupy a single line.

Remember:
1. Each public key occupies ONE LINE in the authorized_keys file.
2. The authorized_keys file must be read-only for the group and others: 644.
3. The .ssh directory can’t be group writable: 755

Disable Password Logins

The goal here is to disallow random hackers guessing at passwords by disabling password logins entirely. Logins will be verified via keys, and we change how SSH behaves by editing the /etc/ssh/sshd_config file.

Make the following edits to the /etc/ssh/sshd_confg file e.g. by typing sudo vi /etc/ssh/sshd_config

Uncomment the PasswordAuthentication line toPasswordAuthentication no

And change the line for PermitRootLogin to:PermitRootLogin no

Then reload the conf:[prompt]$ sudo /etc/init.d/sshd condrestart

WARNING: KEEP THAT WINDOW OPEN. Open a new window, then try to login as your user once again. You shouldn’t be prompted for your password… you should be prompted for your passphrase — this is the passphrase you created when you created your key.

And finally, attempt to login as the root user from your desktop. It should fail.

Summary

Congratulations! If you’ve gotten this far, you’ve taken some big steps in securing your server.

Once you’ve verified that all of this stuff works, you can close the login windows. If something did not work, LEAVE THOSE WINDOWS OPEN and call a friend — find someone who knows Linux system administration to help you out. This is even more important if you don’t have physical access to your server.