What are best practices for accessing my EC2 Linux instance securely using SSH while avoiding unauthorized access?

Last updated: 2020-09-04

I want to access my Amazon Elastic Compute Cloud (Amazon EC2) instance using SSH. What are best practices for keeping my instance secure and avoiding unauthorized access when using SSH?

Resolution

Note: Run the following commands with root privileges. Run the sudo -i command to become the root user.

Don't allow the root user to use an SSH terminal

This is the default for Amazon-provided AMIs and most vendors from the AWS Marketplace. If your instance allows the root user to log in, follow the steps below to deny access.

1.    Add an * (asterisk) to the password field in the /etc/shadow file to invalidate the root user's password:

Edit the file with vipw -s.

The first line is usually the root user's line. Change the root user's line as follows:

root:*LOCK*:14600::::::

2.    Edit the SSH daemon's config file using an editor such as the vi editor:

vi /etc/ssh/sshd_config

Make sure that the following line is present and uncommented. This line denies login permission to the root user.

PermitRootLogin no

3.    Restart the SSH daemon:

service sshd restart

For information on other parameters of the PermitRootLogin option, see OpenBSD manual page server on the man.openbsd.org website.

Be sure that all users log in with an SSH key pair, and then disable password authentication

The default configuration for Amazon provided AMIs is logging in with an SSH key pair with password authentication disabled. If you've altered your instance, revert to the default configuration using the following commands:

1.    Use the vi editor, or editor of your choice, to access the sshd_config file:

vi /etc/ssh/sshd_config

2.    Verify that the following line is present and uncommented:

PasswordAuthentication no

3.    Restart the SSH daemon:

service sshd restart

Users will need their public keys inside ~/.ssh/authorized_keys. For more information on key-based logins, see Amazon EC2 key pairs and Linux instances.

Restrict access from unknown sources

For public instances, having the SSH port open and unrestricted might allow intrusions if misconfigurations exist or if there are unexpected software vulnerabilities. To help prevent intrusions, follow these best practices:

1.    Keep the SSH daemon updated to the latest version supplied by your Linux distribution maintainer. Often the SSH daemon receives backport updates from later releases from the upstream provider. For more information on backporting, see Backporting security fixes on the Red Hat Customer Portal website.

yum -y install openssh-server # for Amazon Linux, RHEL, Centos
apt update && apt install openssh-server # For Ubuntu, Debian

2.    Restrict your security group to allow incoming connections to port 22 from trusted IPs only, such as corporate network IPs. For more information, see Authorizing inbound traffic for your Linux instances

3.    Some intruders might try to guess user names and passwords, or might try to overflow your SSH daemon if port 22 is opened to the world. fail2ban is a utility that monitors your log files for constant attempts to log in to your instance and then blocks them after a few unsuccessful attempts. To install fail2ban:

Ubuntu:

apt -y install fail2ban

Amazon Linux, Centos, RHEL:

Install the EPEL repository.

Run the following commands:

yum -y install fail2ban
systemctl enable fail2ban
systemctl start fail2ban

For details on how to configure fail2ban, see Linux security: Protect your systems with fail2ban on the Red Hat website.

Use AWS Systems Manager Session Manager for shell access to EC2 instances

Session Manager allows AWS Identity and Access Management (IAM) users to log in to your instances with encryption and logging capabilities. Systems Manager's traffic goes through the Systems Manager Endpoint, allowing easy and secure access to private instances without opening inbound ports. For more information about Session Manager, see AWS Systems Manager Session Manager for shell access to EC2 instances.


Did this article help?


Do you need billing or technical support?