- Più recenti
- Maggior numero di voti
- Maggior numero di commenti
Based on the information provided, there are a few potential reasons why you're encountering the "Permission denied (public key)" error while your colleague can still access the instance:
-
Incorrect location of authorized_keys file: It appears you've added your colleague's public key to a separate authorized_keys file in their home directory (/home/mycolleague/.ssh/authorized_keys). However, the SSH daemon typically looks for the authorized_keys file in the home directory of the user you're trying to log in as. If you're using a different user (e.g., ec2-user or ubuntu), your public key should be in that user's authorized_keys file.
-
Permissions issues: The permissions on the .ssh directory and authorized_keys file are critical. While you've set the correct permissions for your colleague's file, make sure the same is true for the main user's .ssh directory and authorized_keys file.
-
Incorrect public key: If you generated a new public key from your .pem file and asked your colleague to add it, there might have been an error in the process. The public key needs to be correctly derived from your private key and properly formatted in the authorized_keys file.
-
SSH configuration changes: If any changes were made to the SSH configuration on the instance, it could affect your ability to connect.
To resolve this issue, you can try the following:
-
Ask your colleague to check the authorized_keys file in the main user's home directory (e.g., /home/ec2-user/.ssh/authorized_keys or /home/ubuntu/.ssh/authorized_keys) and ensure your public key is correctly added there.
-
Verify the permissions on the .ssh directory and authorized_keys file for the main user:
- .ssh directory should be 700 (drwx------)
- authorized_keys file should be 600 (-rw-------)
-
Double-check that you're using the correct username when attempting to SSH (e.g., ec2-user@your-instance-ip or ubuntu@your-instance-ip).
-
If all else fails, you may need to use one of the recovery methods for lost EC2 key pairs, such as:
- Using EC2 Instance Connect (if enabled)
- Stopping the instance, detaching the root volume, attaching it to a new instance, modifying the authorized_keys file, and then reattaching the volume to the original instance
Remember to always keep backups of your key pairs and regularly review and update your instance access methods to prevent future lockouts.
Sources
Community | Recovering Access: A Guide for Lost EC2 Key Pair in Linux
Tutorial: Complete the configuration required to connect to your instance using EC2 Instance Connect - Amazon Elastic Compute Cloud
How to Recover Access to Your EC2 Instance After Losing the Private Key | AWS re:Post

My colleague does not have permissions to see /home/ubuntu/.ssh/authorized_keys