As soon as you have your IP address and password for your Server, login via SSH:
If you rebuilt your Server, you may get a message informing you that the “remote host identification has changed”.
When you log into a Server via SSH, one of the security features is matching the remote host with known keys. When you rebuild a Server, the remote host key changes. As such, your computer thinks there is something dodgy going on.
All you need to do is remove the older entry for the Server IP:
On your LOCAL computer, edit the SSH known_hosts file and remove any entries that point to your Server IP address.
If you are not using Linux or a Mac on your LOCAL computer, the location of the known_hosts file will differ. Please refer to your own OS for details of where this file is kept.
Once logged in to the VPS, immediately change your root password to one of your choosing:
Add an admin user (I’ve used the name demo here but any name will do).
This should run you through a list of questions regarding setting up the user.
User ID ('UID') [ defaults to next available ]:
Hit enter to give it a default UID.
Initial group [ users ]:
Choose the default once again by hitting Enter.
Additional groups (comma separated) :
We don't need this user in any additional groups for now, so hit Enter.
Home directory [ /home/demo ]
The default home directory is fine for now, so hit Enter.
Shell [ /bin/bash ]
Unless you have a need for a different shell, the default BASH shell is just fine. Hit Enter.
Expiry date (YYYY-MM-DD) :
We want this account to be permanent, so hit Enter for the default non-expiration.
With all of those questions done, you should receive the following output:
New account will be created as follows: --------------------------------------- Login name.......: demo UID..............: [ Next available ] Initial group....: users Additional groups: [ None ] Home directory...: /home/demo Shell............: /bin/bash Expiry date......: [ Never ] This is it... if you want to bail out, hit Control-C. Otherwise, press ENTER to go ahead and make the account.
Look over the output to make sure it looks correct, then hit Enter. If you made a mistake somewhere, hit Control-C and start the user addition process over.
The account is now created, and now Arch will ask you for some information about this user. None of it is required, but it can be useful for managing a multiple user system. For anything that you do not wish to enter, just leave it blank and hit the Enter key.
The last question you will be presented with is:
Enter new UNIX password:
Provide a password for this account.
Retype new UNIX password:
passwd: password updated successfully Account setup complete.
Woo! We've set up our first user.
As you know, we never log in as the root user (this initial setup is the only time you would need to log in as root). As such, the main administration user (demo) needs to have sudo (Super User) privileges so they can, with a password, complete administrative tasks.
We will give sudo privileges to all users who belong to the wheel group.
To configure this, give the visudo command:
Find the line that reads:
# %wheel ALL=(ALL) ALL
and uncomment it by removing the '# ' (hash and space), so it looks like this:
%wheel ALL=(ALL) ALL
Save the changes by hitting these key combinations: ESC, then :wq!
Now we’ll add demo to the wheel group; giving him the ability to use sudo:
usermod -aG wheel demo
Again, replace demo with whatever name you chose above.
One effective way of securing SSH access to your server is to use a public/private key. This means that a public key is placed on the server and the private key is on our local workstation. This makes it impossible for someone to log in using just a password - they must have the private key.
The first step is to create a folder to hold your keys. On your LOCAL workstation:
That’s assuming you use Linux or a Mac and the folder does not exist. There will be a separate article for key generation using Putty for Windows users.
To create the ssh keys, on your LOCAL workstation enter:
ssh-keygen -t rsa
If you do not want a passphrase then just press enter when prompted.
That created two files in the .ssh directory: id-rsa and id-rsa.pub. The pub file holds the public key. This is the file that is placed on the Server.
The other file is your private key. Never show, give away or keep this file on a public computer.
Now we need to get the public key file onto the Server.
We’ll use the scp (secure copy) command for this as it is an easy and secure means of transferring files.
Still on your LOCAL workstation enter this command:
scp ~/.ssh/id_rsa.pub firstname.lastname@example.org:/home/demo/
When prompted, enter the demo user password.
Change the IP address to your server and the location to your admin user’s home directory (remember the admin user in this example is called demo).
OK, so now we’ve created the public/private keys and we’ve copied the public key onto the Server.
Now we need to sort out a few permissions for the ssh key.
On your Server, there’s a directory called .ssh in the demo user’s home folder, lets move the pub key into it:
mv /home/demo/id_rsa.pub /home/demo/.ssh/authorized_keys
Now we can set the correct permissions on the key:
chmod 600 /home/demo/.ssh/authorized_keys
Done. It may seem a long set of steps but when you have done it once, you can see the order of things: create the key on your local workstation, copy the public key to the Server and set the correct permissions for the key.
Next we’ll change the default SSH configuration to make it more secure:
The main things to change (or check) are:
# Change the default port to something else: Change: #Port 22 to: Port 30000 # (Actually change it to something generic, 30000 is just an example) # Don't allow root to login through ssh Change: #PermitRootLogin yes to: PermitRootLogin no # Specify which users can login via ssh. Add this line to the bottom of the file. # More users can be addded using `space` as a separator, eg. demo anne jenny AllowUsers demo
Once done, save the file and exit the editor using the same commands as earlier. I think the settings are fairly self explanatory but the main thing is to move it from the default port of 22 to one of your choosing, turn off root logins and define which users can log in.
PasswordAuthentication has been turned off as we setup the public/private key earlier. Do note that if you intend to access your server from different computers you may want leave PasswordAuthentication set to yes. Only use the private key if the local computer is secure (i.e. don’t put the private key on a work computer).
Note that we haven’t enabled the new settings - we will restart SSH in a moment but first we need to create a simple firewall using iptables.
Now that we've secured SSH, let's make sure that we're using the newest package list and most updated packages on our server. Arch uses the pacman package manager.
Before we start updating, we need to make a change to the repository list. The default repository of ftp://ftp.archlinux.org/ is speed and user capped, so let's make sure we're not using it and instead using one of the other official mirrors. The mirrorlist for the repository is located at /etc/pacman.d/mirrorlist, so let's open it up.
You can, of course, use another editor such as nano.
This'll give you a list of repositories that'll start with something like this:
# # Arch Linux repository mirrorlist # # North America # - United States Server = ftp://ftp.archlinux.org/$repo/os/x86_64 Server = ftp://locke.suu.edu/linux/dist/archlinux/$repo/os/x86_64 Server = http://archlinux.unixheads.org/$repo/os/x86_64 Server = ftp://ftp.gtlib.gatech.edu/pub/linux/distributions/archlinux/$repo/os/x86_64 Server = ftp://mirror.cs.vt.edu/pub/ArchLinux/$repo/os/x86_64 Server = http://mirrors.easynews.com/linux/archlinux/$repo/os/x86_64
We want to comment out the first server listed. Put a # in front of it, so it looks like this:
# # Arch Linux repository mirrorlist # # North America # - United States # Server = ftp://ftp.archlinux.org/$repo/os/x86_64 Server = ftp://locke.suu.edu/linux/dist/archlinux/$repo/os/x86_64 Server = http://archlinux.unixheads.org/$repo/os/x86_64 Server = ftp://ftp.gtlib.gatech.edu/pub/linux/distributions/archlinux/$repo/os/x86_64 Server = ftp://mirror.cs.vt.edu/pub/ArchLinux/$repo/os/x86_64 Server = http://mirrors.easynews.com/linux/archlinux/$repo/os/x86_64
Save and close out your editor.
To prevent an upgrade conflict, a symbolic link needs to be removed:
Now that we've removed the speed-capped repository and removed all possible sources of upgrade conflict, we can proceed with our updating and upgrading.
pacman --sync --refresh --sysupgrade
That will give you a screen that looks like this:
:: Synchronizing package databases... core 32.4K 1351.5K/s 00:00:00 [##################################################################] 100% extra 379.1K 51.9K/s 00:00:07 [##################################################################] 100% community 366.3K 58.8K/s 00:00:06 [##################################################################] 100% :: Starting full system upgrade... :: Replace man with core/man-db? [Y/n]
Hit Enter to choose yes. You may see a warning or two (such as one about forcing a ruby upgrade), ignore them. Next, you'll be faced with:
:: pacman has detected a newer version of itself. :: Do you want to cancel the current operation :: and install the new pacman version now? [Y/n]
Hit Enter to choose yes again, and you'll see this:
resolving dependencies... looking for inter-conflicts... Targets: libarchive-2.6.1-1 pacman-mirrorlist-20090108-1 pacman-3.2.2-1 Total Download Size: 0.84 MB Total Installed Size: 2.82 MB Proceed with installation? [Y/n]
Obviously, we want to proceed, so hit Enter for the default yes choice.
Now that pacman is updated to the newest version, run the update/upgrade command again:
pacman --sync --refresh --sysupgrade
You'll once again be faced with this query:
:: Replace man with core/man-db? [Y/n]
As usual, hit Enter to choose the default yes choice.
Now Arch will list a whole bunch of package targets and tell you the total download and installed size, then ask you if it wants to proceed.
Proceed with installation? [Y/n]
Well, we've come this far! Might as well hit Enter to choose the default yes choice. You'll be downloading and installing a bit over 100 packages, so this part will take a few minutes. Sit back, relax, and watch the hash marks scroll!
As said, the next thing is to set up our iptables so we have a more secure installation. To start with, we’re going to have three ports open: ssh, http and https.
Note that we are logged in as the root user. This is the only time we will log in as the root user. As such, if you are completing this step at a later date using the admin user, you will need to put a sudo in front of the commands.
Arch comes with iptables installed by default, but without any rules active. To confirm this, type:
You will see something similar to this:
Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination
As you can see, we are accepting anything from anyone on any port and allowing anything to happen.
One theory is that if there are no services running then it doesn’t matter. I disagree. If connections to unused (and popular) ports are blocked or dropped, then the vast majority of script kiddies will move on to another machine where ports are accepting connections. It takes ten minutes to set up a firewall - is it really worth not doing?
Seeing as we’ve come so far, let’s assume you’ve decided that you want a firewall.
Once it finishes installing, we’ll start adding our rules. Run these commands in the shell. Remember to change 30000 to whichever port you chose to run ssh on:
iptables -P INPUT ACCEPT iptables -P OUTPUT ACCEPT iptables -A INPUT -i lo -j ACCEPT iptables -A INPUT -d 127.0.0.0/8 -i ! lo -j REJECT --reject-with icmp-port-unreachable iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 30000 -j ACCEPT iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT iptables -A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT iptables -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT iptables -A INPUT -j REJECT --reject-with icmp-port-unreachable
Once you’ve entered these commands you can see that iptables is fully loaded with:
Notice the change? (If there is no change in the output, you did something wrong. Try again from the start).
Have a look at the rules and see exactly what is being accepted, rejected and dropped; make sure this is what you want. If something goes wrong, you can start again by typing:
Once you are happy with the rules, it’s time to save our rules permanently:
The table is saved to /etc/iptables/iptables.rules if you need to change something in the future, you can edit this file and reload iptables with:
sudo nano /etc/iptables/iptables.rules /etc/rc.d/iptables restart
Now that we have an iptables configuration that we're happy with, let's make sure that it loads after a reboot. We'll need to edit the /etc/rc.conf file to do this.
sudo nano /etc/rc.conf
Look for the line that deals with daemons:
... DAEMONS=(syslog-ng network netfs crond sshd) ...
Add in iptables between syslog-ng and network, so that the line looks like this:
... DAEMONS=(syslog-ng iptables network netfs crond sshd) ...
Save the file and exit your editor. Now iptables will start on boot!
Now we have our basic firewall humming along and we’ve set up the ssh configuration. Now we need to test it. Reload ssh so it uses the new ports and configurations:
Don’t logout yet…
As you have an already established connection you will not be locked out of your ssh session (look at the iptables config file: it accepts already established connections).
On your LOCAL computer, open a new terminal and log in using the administration user (in this case, demo) to the port number you configured in the sshd_config file:
ssh -p 30000 email@example.com
Cloud Servers also has the excellent ajax console so if it all goes horribly wrong, you can log into your server from the Cloud Services Control Panel area.
If all goes well you should login without a password to a plain terminal:
demo@yourvpsname ~ $
We now know that our system is updated, the firewall and ssh works, and that we can log in. You now have a secure Arch Cloud Server that's ready to be configured as a server or development environment!
© 2011-2013 Rackspace US, Inc.
Except where otherwise noted, content on this site is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License