Skip to content

How do I access my Amazon 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 SSH. However, I want to block unauthorized access.

Short description

Use the following best practices to secure your instances when you access EC2 instances with SSH:

  • Use AWS Systems Manager to manage AWS Identity and Access Management (IAM) user access.
    -or-
    Use Amazon EC2 Instance Connect for shell access to the 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.

Resolution

Prerequisite: You must run commands in the following resolution steps with root user permissions. To become the root user, run the following command:

sudo -i 

Set up access to your instance

Use Systems Manager

With Session Manager, a capability of AWS Systems Manager, IAM users can log in to your instances with encryption and logging capabilities. For Session Manager, you don't need to open inbound ports on the instance's security group. For private instances, the traffic to Systems Manager goes through the Systems Manager interface endpoints and allows only secure access.

Use EC2 Instance Connect

Use EC2 Instance Connect to connect to your instances. EC2 Instance Connect uses your existing IAM roles and policies.

For private instances, create an EC2 Instance Connect Endpoint in your virtual private cloud (VPC) for access. For more information, see Connect to your instances using a private IP address and EC2 Instance Connect Endpoint.

Don't allow the root user to use an SSH terminal and make sure that all users log in with an SSH key pair

By default, Amazon provided Amazon Machine Images (AMIs) and most vendors from the AWS Marketplace don't allow root user logins from an SSH terminal. Amazon provided AMIs also require users to log in with an SSH key pair and block access with a password. This configuration protects your instance from security risks. For example, an unauthorized user might guess a weak password to gain access.

Important: Make sure that you create key pairs before you deactivate password authentication so that you don't lose SSH access to the instance. Each user must import their public keys in the ~/.ssh/authorized_keys format.

If your instance allows the root user to log in or password authentication, then complete the following steps to revert to the default configuration:

  1. Run the following command to edit the /etc/shadow file:

    vipw -s
  2. Add an asterisk (*) to the password field to make the root user's password not valid.
    Example line:

    root:*EXAMPLEPASSWORD*:14600::::::
  3. Edit the SSH configuration file with a text editor. For example, run the following command to edit the file in the vi editor:

    vi /etc/ssh/sshd_config
  4. Make sure that the following line is present and uncommented:

    PermitRootLogin no

    Note: The preceding line blocks the root user. For information about the PermitRootLogin option, see sshd_config on the OpenBSD website.

  5. Navigate to the /etc/ssh/sshd_config.d directory and review all files within it. If any file contains a commented PermitRootLogin no line, then uncomment the line to prevent configuration overrides.

  6. Run the following command to restart the SSH daemon:

    systemctl restart sshd

Restrict access from unknown sources

For public instances, it's not a best practice to keep the SSH port open and unrestricted. To restrict access to the SSH port, take the following actions.

Keep the SSH daemon updated

Run the following command based on your Linux distribution to update the SSH daemon to the latest version for your Linux distribution.

Amazon Linux, Red Hat Enterprise Linux (RHEL), or Centos:

yum -y install openssh-server

Ubuntu or Debian:

apt update && apt install openssh-server

Note: The SSH daemon typically receives backport updates from the upstream provider's later releases. For more information about backporting, see Backporting security fixes on the Red Hat Customer Portal website.

Restrict inbound connections

Update your security group to allow inbound connections to the SSH port only from trusted IP addresses, such as corporate network IP addresses. By default, the SSH port is port 22.

Block repeated unsuccessful logins with fail2ban

If you must keep the SSH port open to all traffic, then make sure that your configuration blocks unauthorized access. With an open SSH port, unauthorized users might try to guess usernames and passwords, or overflow your SSH daemon with access requests. Use the fail2ban utility to monitor your log files for repeated login attempts to your instance. If the utility notes too many login attempts, then the utility blocks further attempts.

For Amazon Linux 2 (AL2), RHEL, and Centos, install the Extra Packages for Enterprise Linux (EPEL) repository. Then, run the following commands to install fail2ban:

sudo yum -y install fail2ban

sudo systemctl enable fail2ban

sudo systemctl start fail2ban

Note: For Amazon Linux 2023 (AL2023), you can directly run the preceding commands. AL2023 doesn't require the EPEL repository.

For Ubuntu and Debian, run the following commands to install fail2ban:

sudo apt update

sudo apt -y install fail2ban

For information about 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 OFFICIALUpdated a month ago
2 Comments

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.

replied 2 years ago

This article was reviewed and updated on 2026-04-03.

AWS
EXPERT
replied a month ago