How do I troubleshoot connecting to my EC2 instance using a secondary IP address?
Last updated: 2020-11-24
I can't connect to my Amazon Elastic Compute Cloud (Amazon EC2) instance using a secondary IP address. How do I troubleshoot this?
To connect to your instance through SSH using a secondary IP address, make sure your instance meets the following prerequisites:
- If you launched your instances in a private subnet, then connect through SSH using the secondary private IP address. Make sure to choose the secondary IPv4 address from the IPv4 CIDR block range of the subnet for the network interface.
- If you launched your instances in a public subnet, then allocate an Elastic IP address to the secondary private IP address attached to your instance.
- Make sure that the operating system on your EC2 instance recognizes the secondary private IP address.
For Amazon Linux, see Configuring the operating system on your instance to recognize secondary private IPv4 addresses.
For Ubuntu, see How can I make my secondary network interface work in my Ubuntu EC2 instance?
For other Linux distributions, see the network configuration documentation for your distribution.
If your instance meets these prerequisites, do the following to troubleshoot connecting through SSH:
- Connect through SSH with verbose messaging on to identify the error.
- Review the system logs to look for errors.
Note: Review the general connection prerequisites before beginning.
Connect through SSH with verbose messaging on to identify the error
For detailed instructions, see How do I troubleshoot problems connecting to my Amazon EC2 Linux instance using SSH?
Review the system logs to look for errors
Warning: Before starting this procedure, be aware that:
- Stopping the instance erases any data on instance store volumes. Be sure that you backup any data on the instance store volume that you want to keep. For more information, see Determining the root device type of your instance.
- Stopping and then starting the instance changes the public IP address of your instance. It's a best practice to use an Elastic IP address instead of a public IP address when routing external traffic to your instance.
If the preceding steps don't resolve the issue, review the instance's system logs:
1. Open the Amazon EC2 console.
2. Choose Instances from the navigation pane, and select instance that you're trying to connect to.
3. Choose Instance State, Stop Instance, and then select Stop. Note the Instance ID.
Note: If you're not using the New EC2 Experience, then select the instance that you're trying to connect to, then choose Actions, Instance State, Stop, Stop.
4. Detach the root Amazon Elastic Block Store (Amazon EBS) volume from the stopped instance. Note the device name of the root EBS volume before detaching it from the stopped instance. The device name is required when you reattach the volume after troubleshooting.
6. Launch a new EC2 instance in the same Availability Zone as the original instance. The new instance becomes your "rescue" instance.
Note: It's a best practice to use an Amazon Linux 2 instance as the rescue instance. Using an Amazon Linux 2 instance prevents the rescue instance from booting off of the attached EBS volume because the UUID or name of the EBS volume being the same.
7. After the rescue instance launches, choose Volumes from the navigation pane, and then select the detached root volume of the impaired instance.
Note: If the impaired instance's root volume has Marketplace codes and the rescue instance isn't Amazon Linux, then stop the rescue instance before attaching the root EBS volume. An instance might have Marketplace codes if you launched the instance from an official RHEL or CentOS AMI, for example.
8. Choose Actions, Attach.
9. Select Instances in the navigation pane, and then select the rescue instance.
10. Choose Instance state, Start instance.
Note: If you're not using the New EC2 Experience console, then select the instance that you're trying to connect to, then choose Actions, Instance State, Start.
11. Connect to the rescue instance through SSH.
12. Run the following command to verify that the EBS volume successfully attached to the rescue instance. In the following command, the volume attached as /dev/sdf.
The following is an example of the command output:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT xvda 202:0 0 20G 0 disk └─xvda1 202:1 0 20G 0 part / xvdf 202:80 0 100G 0 disk
13. Use the following commands to create a mount point directory, and then mount the attached volume to the rescue instance. In the following example, the mount point directory is /test.
$ sudo su $ mkdir /test $ mount /dev/xvdf1 /test $ df -h $ cd /test
14. Locate errors in the system logs and authentication-related logs that are timestamped with the times that you attempted access.
Amazon Linux, RHEL, CentOS
$ sudo cat /test/var/log/messages
Amazon Linux, RHEL, CentOS (Authentication-related issues)
$ sudo cat /test/var/log/secure
Ubuntu, Debian (System Logs)
$ sudo cat /test/var/log/syslog
Ubuntu, Debian (Authentication-related issues)
$ sudo cat /test/var/log/auth.log
15. After reviewing the configurations and addressing any errors, unmount and detach the EBS root volume from the rescue instance.
$ umount /test
16. Attach the volume to the original instance. The device name is /dev/xvda.