Short description
First, check your EC2 instance configuration and make sure that the instance passes the instance and system statuses.
If you still can't connect, then restore your connection for SSH, EC2 Instance Connect, or Session Manager, a capability of AWS Systems Manager. Or, use the EC2 Serial Console to restore your connection.
Note: Typically, you use the EC2 Serial Console only to troubleshoot issues, not to perform standard processes.
If one connection method doesn't work, then use another connection method to access your instance and troubleshoot issues.
If you still can't restore your connection, then use a rescue instance to check the affected instance's logs for errors.
Resolution
Note: If you receive errors when you run AWS Command Line Interface (AWS CLI) commands, then see Troubleshooting errors for the AWS CLI. Also, make sure that you're using the most recent AWS CLI version.
Check the configuration of your instance access
Review your security group rules
The inbound security group rules must allow access from your IP address to port 22 for Linux and port 3389 for Windows.
To check your security group rules, run the following describe-security-groups AWS CLI command:
aws ec2 describe-security-groups --group-ids SG-IDs
Note: Replace SG-IDs with your security group IDs.
If port 22 or 3389 aren't on your allowlist, then run the following authorize-security-group-ingress command to update your rules to allow access:
aws ec2 authorize-security-group-ingress --group-id SG-ID --protocol tcp --port 22 --cidr SOURCE-IP/32
Note: Replace SG-ID with your security group ID and SOURCE-IP with your source IP address. If you use a Windows instance, then replace 22 with 3389. If the source IP address is a public IP address, you can use the checkip.amazonaws.com tool to identify the IP address.
Review your network ACLs
By default, network access control lists (network ACLs) allow all inbound and outbound traffic. Make sure that your network ACLs allow inbound SSH access to the instance and outbound access to ephemeral ports (1024-65535). If the network ACLs block port 22 or 3389, then add a new rule to allow the traffic. For public IP addresses, make sure that the route table has an entry that routes traffic to an internet gateway.
Check your route table
Verify that your route table has a route for the connection.
Make sure that your instance passes its status checks
To connect to an instance, the instance must pass its status checks. Use the Amazon EC2 console to check whether System status and Instance status both show OK. You can also use Amazon CloudWatch metrics to check the status of your instance and identify issues that affect connectivity.
Note: It's a best practice to check for scheduled maintenance and other events that can affect the instance connectivity.
If the Instance status isn't OK, then reboot your instance. An instance reboot typically resolves minor issues. If you still can't connect, or System status isn't OK, then the issue might be the AWS infrastructure. To resolve this issue, see Why is my Amazon EC2 instance down with a system status check failure?
If you still encounter issues, then see How do I troubleshoot status check failures for my EC2 Linux instance? or Why is my EC2 Windows instance down with an instance status check failure?
Troubleshoot connection errors
If your instance passes status checks, but you get connection errors, then see the following resources:
Restore your SSH connection
Note: If you lost your SSH key pair, then see How do I connect to my Amazon EC2 instance if I lose my SSH key pair after the initial instance launch?
Review your username and IP address settings
Make sure that you use the correct username for your instance. Then, connect to the instance from a public IP address.
Note: If you connect from a private IP address, then make sure that you have a working network connection to the destination instance.
Check the SSH server status
To check the status of the SSH server, use Session Manager, EC2 Instance Connect or the EC2 Serial Console to connect to the instance.
Run the following command to check the status of the SSH service based on your distribution:
Systems that use systemd:
sudo systemctl status sshd
Ubuntu or Debian systems:
sudo systemctl status ssh
Legacy systems, such as CentOS 6:
sudo service sshd status
If the SSH service status is Stopped, then run the following command to start the service based on your distribution:
Systems that use systemd:
sudo systemctl start sshd
Ubuntu or Debian systems:
systemctl start ssh
Legacy systems, such as CentOS 6:
sudo service sshd start
Review your private key file permissions
Make sure that your private key file has the required read permissions.
Test network connectivity
To test connectivity to port 22, run one of the following commands from your client:
nc -zv Host 22
-or-
telnet Host 22
Note: Replace Host with your IP address or the fully qualified domain name (FQDN).
Then, run the following command to use SSH connect to your instance in verbose mode:
ssh -i key_pair.pem user@Host -vvv
Note: Replace Host with your IP address or the FQDN.
To troubleshoot connection issues, see, How do I troubleshoot "Connection refused" or "Connection timed out" errors when I use SSH to connect to my EC2 instance? and Troubleshoot issues connecting to your Amazon EC2 Linux instance.
Restore your EC2 Instance Connect connection
First, use SSH, Session Manager or the EC2 Serial Console to connect to your instance to make sure that you installed EC2 Instance Connect. Then, use EC2 Instance Connect to connect to the instance.
If you experience issues when you use EC2 Instance Connect, then make sure that you allow inbound SSH traffic on port 22 for the com.amazonaws.region.ec2-instance-connect prefix list name. Also, verify that your AWS Identity and Access Management (IAM) user's policy includes the ec2-instance-connect:SendSSHPublicKey action.
If you still experience issues, then see How do I troubleshoot errors that I receive when I use EC2 Instance Connect to connect to my EC2 instance?
Use the EC2 Serial Console to restore connection
Prerequisite: Configure access to the EC2 Serial Console.
To use the EC2 Serial Console to connect to your instance, you can use the Amazon EC2 console or SSH. For more information, see How do I access the EC2 Serial Console of an unreachable or inaccessible Linux instance?
After you connect, troubleshoot your instance for boot, network configuration, or other issues.
If you experience issues when you use EC2 Serial Console, then make sure that your IAM policy includes the ec2-instance-connect:SendSerialConsoleSSHPublicKey action.
Restore your Session Manager connection
Session Manager manages authentication only through IAM roles and permissions instead of through SSH keys. Before you use Session Manager, make sure that you adhere to the prerequisites for Session Manager. Then, use Session Manager to connect to your instance.
If you experience issues when you use Session Manager, then take the following actions.
Check your IAM roles
Confirm that the instance has an IAM role with the AmazonSSMManagedInstanceCore policy attached.
Or, make sure that the role has the following required permissions:
- ssmmessages:CreateControlChannel
- ssmmessages:CreateDataChannel
- ssmmessages:OpenControlChannel
- ssmmessages:OpenDataChannel
You can add the required Session Manager permissions to an existing role.
Note: If you use Default Host Management Configuration to manage your instances, then you don't need to create an IAM instance profile to manage instances.
If you update the permissions, then detach and reattach the IAM role. Wait for couple of minutes, and then start AWS Systems Manager Agent (SSM Agent) or start the instance.
Troubleshoot the SSM Agent status
Verify that you installed SSM Agent on the instance.
Use SSH, EC2 Serial Console, or EC2 Instance Connect to connect to your instance. Then, run the following command to check the status of the SSM Agent based on your distribution.
Systems that use systemd:
sudo systemctl status amazon-ssm-agent
Debian or Ubuntu systems:
sudo systemctl status snap.amazon-ssm-agent.amazon-ssm-agent.service
If the agent status is Stopped, then run the following command to start it, based on your distribution.
Systems that use systemd:
sudo systemctl start amazon-ssm-agent
Debian or Ubuntu systems:
sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service
To verify that SSM Agent is running, check the system log.
It's a best practice to use the latest version of SSM Agent. To check whether you have the latest version, see amazon-ssm-agent/RELEASENOTES on the GitHub website. If you don't have the latest version, then install an updated SSM Agent based on your operating system (OS).
To further troubleshoot, check the /var/log/amazon/ssm/amazon-ssm-agent.log logs for errors. Or, see Troubleshooting SSM Agent.
Verify network connectivity
Make sure that your network ACLs and security groups allow an outbound connection to the AWS Systems Manager endpoint on port 443.
If your instance doesn't appear in Session Manager, then see Why isn't Systems Manager showing my Amazon EC2 instance as a managed instance?
For private instances, create virtual private cloud (VPC) endpoints. For Service name, select com.amazonaws.REGION.ssm and com.amazonaws.REGION.ssmmessages.
Note: Replace REGION with your AWS Region.
The security group that you attach to the VPC endpoints must allow inbound traffic on port 443.
For more information, see Unable to connect to SSM endpoints.
Check for missing prerequisites
Use SSH, EC2 Serial Console, or EC2 Instance Connect to connect to your instance, and then run the following command to troubleshoot managed node availability:
sudo ssm-cli get-diagnostics --output table
Check the output for Session Manager prerequisites that you're missing.
Or, run a Systems Manager runbook to automatically check for missing prerequisites. Run AWSSupport-TroubleshootManagedInstance to check your VPC configuration, including security group rules, VPC endpoints, network ACL rules, route tables, and IAM profiles. Or, run the AWSSupport-TroubleshootSessionManager to check whether you adhere to the Session Manager prerequisites.
Check instance console logs
If you can't use the preceding methods to connect to your instance, then run the following user data script to restore the Session Manager connection:
Content-Type: multipart/mixed; boundary="//"MIME-Version: 1.0
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
#cloud-config
cloud_final_modules:
- [scripts-user, always]
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"
#!/bin/bash
sudo ssm-cli get-diagnostics --output table >> /dev/console
# or
sudo ssm-cli get-diagnostics --output table >> /dev/ttyS0
Then, check the instance console output to identify the connection step that's failing. After you troubleshoot the failing step, use Session Manager to test your connection.
If you still can't connect, then use a rescue instance to troubleshoot boot issues.
Related information
Troubleshoot issues with Amazon EC2 instances