I was running memph.us on an Ubuntu cloud server powered by Rackspace, but I decided to give GoGrid a try by creating a CentOS cloud server (GoGrid doesn’t offer Ubuntu as a choice, but that’s okay because this helped me familiarize myself more with CentOS server). Once I created the CentOS cloud server, I opened a terminal and logged into it via SSH:
ssh root@123.45.67.890
The first thing I did upon logging in was changing the root password:
passwd
After this, I modified my sudo configuration by running this command:
/usr/sbin/visudo
Now, I’m not sure if this is a CentOS feature, because I’ve never seen it in Ubuntu so I had to look it up, but there is a group ‘wheel’ that designates users with sudo privileges. I found the following line in the sudo config:
## Allows people in group wheel to run all commands
# %wheel ALL=(ALL) ALL
and removed the # so that the %wheel line was no longer commented out:
## Allows people in group wheel to run all commands
%wheel ALL=(ALL) ALL
I saved /usr/sbin/visudo, so now I need to add a user that can belong to the ‘wheel’ that isn’t root but still has sudo privileges:
/usr/sbin/adduser demo
I also set a password for my user (I’m using demo for the example, but it can be whatever you want):
passwd demo
Now that I’ve created this user, it needs to have sudo privileges by being added to the ‘wheel’:
/usr/sbin/usermod -a -G wheel demo
The next step is optional but recommended. I wanted to create a public/private key pair to secure access to my server, so in a LOCAL shell, I ran this command:
ssh-keygen -t rsa
I created a path on my LOCAL machine for the keys to be stored is:
mkdir ~/.ssh
The files created are id_rsa and id_rsa.pub. id_rsa is the private key that stays on your computer. NEVER share it and NEVER store it on a public computer! The public key (id_rsa.pub) needs to go on the server, however:
scp ~/.ssh/id_rsa.pub demo@123.45.67.890:
Now, my server needs a directory for the public key to reside in:
mkdir ~demo/.ssh
mv ~demo/id_rsa.pub ~demo/.ssh/authorized_keys
Once it’s placed here, permissions need to be set for the key:
chown -R demo:demo ~demo/.ssh
chmod 700 ~demo/.ssh
chmod 600 ~demo/.ssh/authorized_keys
To create another user, simply repeat these processes. If you’re done creating users, then proceed to the next step:
The default SSH config should be changed to be more secure:
nano /etc/ssh/sshd_config
(click here for an example ssh configuration that can be used)
The sections of sshd_config that should be checked or changed are the following:
Port 30000 <--- change to a port of your choosing
Protocol 2
PermitRootLogin no
PasswordAuthentication no
X11Forwarding no
UsePAM no
UseDNS no
AllowUsers demo
(note: remember your port number you assign because it’s important for continuing the setup, and the port number can be any integer between 1025 and 65536 (inclusive))
Once these areas are checked, the file can be saved. Optionally, you can enable PasswordAuthentication if you need access to the server but you’re at a computer that doesn’t have your key pair.
The next step is to configure iptables (firewall) to have a more secure installation. You can view the iptables rules with the following command:
/sbin/iptables -L
which will output something like this:
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT esp -- anywhere anywhere
ACCEPT ah -- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp -- anywhere anywhere udp dpt:ipp
ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
These rules can be used, but to add your own rules, the current iptables rules need to be flushed:
/sbin/iptables -F
Now that they’re flushed, we can create our own iptables rule set (click here for a good example set of iptables rules to put into the following file):
nano /etc/iptables.up.rules
Once the content from the example iptables file is copied into iptables.up.rules, we need to tell iptables to use the new rules:
/sbin/iptables-restore < /etc/iptables.up.rules
You can confirm that the iptables rules are altered by checking the iptables rules again:
/sbin/iptables -L
You should notice a difference in the output, which confirms that the rules are changed. The rules are only active for the current session, so they need to be saved to work for all future sessions:
/sbin/service iptables save
The output confirms that the rules are added to the correct file:
Saving firewall rules to /etc/sysconfig/iptables: [ OK ]
If you want to edit/restore the iptables rules later, you can run these commands:
nano /etc/iptables.up.rules
/sbin/iptables -F
/sbin/iptables-restore < /etc/iptables.up.rules
/sbin/service iptables save
Now, we need to reload ssh for it to use the new ports and configurations:
/etc/init.d/sshd reload
Stay logged in as root and open a new shell from your local machine so you can log in as the new admin user you created (demo in our case):
ssh -p 30000 demo@123.45.67.890
(change 30000 to whatever port number you decided to use)
If you followed the steps and your setup is correct, you should see a terminal prompt like this upon entering your password:
[demo@yourvpsname ~]$
You now have ssh access to your server!
(After I installed base programs such as Apache, MySQL, PHP, and WordPress, I used the Slicehost Pro iPhone app to point memph.us to the GoGrid cloud server IP address since I was already using the Slicehost Pro app to manage memph.us when it was on Rackspace. Thanks to slicehost.com for the helpful articles and to Michael Mayo for creating the very helpful Slicehost Pro iPhone app!)