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.
This is what a brute-force attack looks like:
[prompt]$ sudo less /var/log/secure
May 31 22:42:12 yourdomain sshd[25711]: Failed password for invalid user alberto from 190.2.35.25
port 32976 ssh2
May 31 22:42:12 yourdomain sshd[25712]: Connection closed by 190.2.35.25
May 31 22:46:11 yourdomain sshd[25714]: Connection closed by 190.2.35.25
May 31 22:56:46 yourdomain sshd[25717]: Invalid user neil from 190.2.35.25
May 31 22:57:10 yourdomain sshd[25717]: reverse mapping checking getaddrinfo for customer-static.someisp.com failed - POSSIBLE BREAK-IN ATTEMPT!
Using Geobytes (or a similar IP address locator), I can see that some hacker-bot in Argentina was guessing both usernames (e.g. alberto, neil) and passwords every few seconds. F*#K!!
Here’s what the solution to this problem entails:
Keys come in pairs: a public key and a private key. You’ll keep your private key on your machine (in a secure place), the public key you upload to the servers you want to connect to.
You can use different algorithms to generate the key; this shows you how to do it using the DSA algorithm, which is considered more secure (as of this writing).
Open your Terminal and type the following, then just press enter for the default file location. (OS X users can just open their Terminal. Windows users will have to use Cygwin or
* Do a man ssh-keygen on your machine to see if you require different options to create a dsa key.
[prompt]$ ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/Users/youruser/.ssh/id_dsa):
Type a passphrase (twice).
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:
+--[ DSA 1024]----+
| o o++o |
| o+ . oo.. |
|++.o .. |
|*o. + . . |
|+. . * S |
| E o . |
| |
| |
| |
+-----------------+
The ASCII art thing is a new feature, allowing folks to visually identify different keys.
For more information about SSH on OS X, please refer to Dave Dribin’s excellent blog:
ssh-agent on Mac OS X 10.5 (Leopard)
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.
If you are still logging in as the root user, you need to create other users:
Create a user:adduser your_username
Create 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
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.
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.
*In VI, you can hit ESC then type :set nu to see line numbers.
Once you’ve pasted in your key, save the file and adjust the permissions:
[prompt]$ chmod 644 ~/.ssh/authorized_keys
[prompt]$ chmod 755 ~/.ssh
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
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.
Try switching to the root account after logging in:[prompt]$ su - root
And finally, attempt to login as the root user from your desktop. It should fail.
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.
Here’s an article I referenced while writing this:
https://www.webmasterworld.com/linux/3285421.htm
-- Everett Griffiths