accidental renaming of authorized_key file

Question

Hi, I'm new to AWS linux administration after our previous admin left.  The previous admin had not left the root password.  I was instructed to remove his access but had accidental renamed the authorized_key file and do not have the root password.  Therefore, the SSH connection does not work anymore.

When I asked the billing department, they directed me to use AWSSupport-ResetAccess runbook to reset the access to the EC2 instance.  After reviewing the information, I have the following questions and would appreciated any assistance:

1.  Does this mean no user would be able to access anything on the server while I'm going through the runbook process?  IE...web servers and application server will be down, etc.
2. Would we loose any data on the server (an EC2 instance)?
3. Would the IP address change?
4. Would the old EC2 key stop work any longer, ie...the previous system admin will not be able to use it to reconnect.
5.  Will It create a new "authorized_key" file on the server, along with new SSH key/EC2 key so we can reconnect?
6. How long does it usually take to go through this runbook?

Any other precautions we need to be aware of before applying it?

Thanks!

PY

Answer

You've tagged this question with **Amazon Linux** so [depending on the version and the region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-connect-prerequisites.html) you may be able to connect to the instance using EC2 Instance Connect https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-connect-methods.html

This would preclude the need for going down the road of using the AWSSupport-ResetAccess runbook.

Once logged in as **ec2-user** you can generate a new keypair, and put the public key into a fresh copy of **/home/ec2-user/.ssh/authorized_keys**, remembering to set the permissions correctly `chmod 600 /home/ec2-user/.ssh/authorized_keys`

You can also `sudo su -` to become the **root** user, and from here change the password.

Answer

I agree with Riku_Kobayashi and others on the following approach.
(1) use session manager if still possible
(2) use user/password if there is one to login and sudo to root 
(3) follow through using "rescue EC2".  Here is the process:

Take a snapshot of the EC2 without access: this is to safeguard before we make any changes
     Launch a new EC2 instance (VM2) in the same zone as the EC2 without access (VM1) 
     Stop VM1
     Find root volume (say Disk1)  of VM1, note down the device path (such as /dev/sda1) and detach it
     Attach Disk1 to VM2
     Mount Disk1 as file system on VM2
     Make the adjustment on authorized_keys  (ok to recreate key pairs and place the public key in)
     Stop VM2 
     Detach Disk1 and attach into VM1 with the right device path 
     Start VM1 and now you should be able to login
     Congratulations !

Please chat with me if you have more questions.

accidental renaming of authorized_key file

Relevant content