How do I access my EC2 Linux instance securely with SSH and avoid unauthorized access?

5 minute read
1

I want to access my Amazon Elastic Compute Cloud (Amazon EC2) instance with Secure Shell (SSH).

Resolution

Use the following to secure your instances when accessing Amazon EC2 with SSH:

  • Use AWS Systems Manager to manage AWS Identity and Access Management (IAM) users access
  • Use EC2 Instance Connect for shell access to EC2 instances
  • Prevent access by AWS account root users who use an SSH terminal
  • Enforce SSH key pair logins and deactivate password authentication
  • Control port access to restrict access from unknown sources

Note: For steps that involve commands, be sure that you run commands with root user permissions. Run the sudo -i command to become the root user.

Use Systems Manager for shell access to EC2 instances

Session Manager, a capability of AWS Systems Manager, allows IAM users to log in to your instances with encryption and logging capabilities. Systems Manager's traffic that goes through the Systems Manager Endpoint allows only secure access to private instances and doesn't require you to open inbound ports. For more information about Session Manager, see AWS Systems Manager Session Manager for shell access to EC2 instances.

Use EC2 Instance Connect for shell access to EC2 instances

Amazon EC2 Instance Connect allows you to use SSH to connect to your Linux instances. If you use EC2 Instance Connect, then IAM roles and policies are retained. For more information about EC2 Instance Connect, see Connect to your Linux instance using EC2 Instance Connect.
Or, place your EC2 instances behind a private subnet without access from the public network. Then, create an EC2 Instance Connect Endpoint on your VPC to access the instances.

For more information on supported Linux distributions and their respective versions, see the EC2 Instance Connect prerequisites documentation.

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

By default, Amazon provided AMIs and most vendors from the AWS Marketplace don't allow the root user to log in from an SSH terminal. If your instance allows the root user to log in, then follow the steps below to deny access.

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

    Edit the file with vipw -s. Change the root user's line as follows:

    root:*LOCK*:14600::::::
  2. Edit the SSH daemon's config file with 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:

    systemctl restart sshd

For information about other parameters of the PermitRootLogin option, see sshd_config on the OpenBSD website.

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

The default configuration for Amazon provided AMIs requires the user to log in with an SSH key pair but disallows access with a password because password authentication is deactivated. This default configuration blocks password-only access to protect your instance from security risks such as brute force attacks. Weak passwords can be cracked to gain access.

If you altered your instance to use a password, then revert to the default configuration with 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:

    systemctl restart sshd

Important: You must have key pairs installed before you deactivate password authentication so that you don't lose SSH access to the EC2 instance. Each user must have their public keys inserted in the path ~/.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, leaving the SSH port open and unrestricted might allow intrusions if there are unexpected software vulnerabilities. To help prevent intrusions, follow these best practices:

Keep the SSH daemon updated
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

Restrict incoming connections
Restrict your security group to allow incoming connections to port 22 from trusted IPs only, such as corporate network IPs. For more information, see Control traffic to your AWS resources using security groups.

Block repeated unsuccessful log ins with fail2ban
If port 22 is open to the world, then some intruders might try to guess user names and passwords, or try to overflow your SSH daemon. The utility fail2ban monitors your log files for repeated login attempts to your instance. If too many login attempts are recorded, then the utility blocks further attempts.

To install fail2ban, follow these steps:

Install fail2ban on Ubuntu

apt -y install fail2ban

Install fail2ban on Amazon Linux, CentOS, or 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.

Related Information

Securing your bastion hosts with amazon ec2 instance connect

AWS OFFICIAL
AWS OFFICIALUpdated 2 months ago
1 Comment

OP: Does the nest-practice comments note make sense? There are so many ways to solve this. My goal is to minimize SSH to make it solid. There are many security things for you to address including DOS and whether you want AWS managed CPUs and how to handle public access etc. if you can, consider locking your EC2 SSH down so SSH isn't available from the internet. Also consider always building the EC2 from Cloudformatiom so it can easily be rebuilt in seconds if needed.

Allen S
replied 4 months ago