Secure Your Instance
Secure Your Instance
While AWS provides its own firewall, there are still things you can do minimize security risks. Here are three things I recommend:
- Create an Alternate User Account to the Default root (ubuntu) Login
- Turn off SSH Access for Default root (ubuntu) Account
- Change the Default Port Used for SSH From 22
1. Create an Alternate User Account
We’ll add a user named “hal”. Replace “hal” with your preferred username in the examples below:
sudo adduser hal
Add your new user to the admin group:
sudo adduser hal admin
Add your new user to the sudoers group. Edit the sudoers file:
sudo nano /etc/sudoers
Add, this line to the sudoers file, in the user privileges section:
hal ALL=(ALL) NOPASSWD:ALL
Now, we’ll create keys for this user so they can login to AWS. Switch to the new user:
su hal
Change to the home directory for this user:
cd /home/hal
Make an SSH directory and set permissions:
mkdir .ssh chmod 700 .ssh
Generate a new key pair:
cd .ssh ssh-keygen -b 1024 -f id_hal -t dsa
Add public key to authorized_keys file:
cat ~/.ssh/id_hal*.pub > ~/.ssh/authorized_keys
Set permissions:
chmod 600 ~/.ssh/*
Move the private key to a temp folder for download to your computer:
cp ~/.ssh/* /tmp chmod 644 /tmp/*
Edit the SSH config file to add the new user:
sudo nano /etc/ssh/sshd_config
Add the new hal account to the AllowUsers field (or create the line if it’s not there):
AllowUsers ubuntu hal
Restart the service
sudo service ssh restart
Download the new key from your computer using your ubuntu account. On your computer, use Terminal:
scp -i ~/.ssh/mailbox.pem ubuntu@ec2-xx-xx-xx-xx.compute-1.amazonaws.com:/tmp/* ~/.ssh
Set permissions and test:
cd ~/.ssh chmod 400 id_hal ssh -i .ssh/id_hal hal@ec2-xx-xx-xx-xx.compute-1.amazonaws.com
If you run into any errors, you can try looking at the log on the AWS server while you attempt to login:
tail -f /var/log/auth.log
Remove the key files from the server’s tmp directory:
rm -rf /tmp/*
2. Turn off SSH Access for Default root (ubuntu) Account
Edit the SSH configuration file again:
sudo nano /etc/ssh/sshd_config
Remove the ubuntu account from the AllowUsers field:
AllowUsers hal
Make sure PermitRootLogin is off:
PermitRootLogin no
Restart the service
sudo service ssh restart
If you encounter difficulty, you can also go back to logging in through the AWS console instance list:
3. Change the default port used for SSH from 22
Edit the SSH configuration file again:
sudo nano /etc/ssh/sshd_config
Change the Port line to a different port number e.g.:
# What ports, IPs and protocols we listen for Port 33322
Return to the AWS console and edit the security group. Add the port # that you chose e.g. 33322. Remove port 22. Make sure to click the Apply Rules button (not pictured); it’s below the Add Rule box.
Restart the service
sudo service ssh restart
Going forward, you’ll need to use -p 33322 (or your chosen port) when you connect via SSH:
ssh -p 33322 -i .ssh/id_hal hal@ec2-xx-xx-xx-xx.compute-1.amazonaws.com
Later, be sure to review Optimizing AWS and follow the steps to secure your MySQL server.
Here are a couple more references for securing your Linux server:
1. Securing an Ubuntu Server
2. Hardening a Linux Server
Please feel free to post corrections, questions or comments below. You can also follow me on Twitter @reifman or email me directly.
I get to “Add public key to authorized_keys file:” and receive “Permission denied.” I tried sudo-ing. Nothing.
Make sure the file exists and that you have access to it. ls -alst for the directory will show you.
After changing the port I couldn’t connect to my instance anymore =/ all ports open in the applied security group, and I always get “connection refused on port xxxx” I tried many ports, maybe I made a mistake changing it, but no luck.
well, I terminated the instance, created a new one, followed the same steps and now it’s working well o.O
You can also use so called SSH bastion to harden security, especially if you manage multiple EC2 instances. I wrote about it in a post http://www.jrslv.com/ssh-bastion/
Nightmares from the early days when I had to do all of this crap to get things like smtp to work. This is horrible. Plus, now I have to pay for the privilege of being my own tech support. I guess Pine is out of the question 🙂