How to connect to EC2 instance? I've LOST my private key! (Amazon Web Services | AWS | SSH | SSM)
How to connect to EC2 instance? I've LOST my private key! (Amazon Web Services | AWS | SSH | SSM)
In this video, I’ll show you how to recover access to your EC2 instance if you lose your private key.
👉 How to Manage Secrets in Terraform - • How to Manage Secrets in Terraform?
👉 Terraform Tips \u0026 Tricks - • Terraform Tips \u0026 Tricks: loops, if-st…
👉 ArgoCD Tutorial - • ArgoCD Tutorial for Beginners: GitOps…
💼 - I’m a Senior Software Engineer at Juniper Networks (11+ years of experience)
📍 - Located in San Francisco Bay Area, CA (US citizen)
🤝 - LinkedIn - https://www.linkedin.com/in/anton-putra
🎙 - Twitter - https://twitter.com/antonvputra
📧 - Email - [email protected]
👨💻 - GitHub - https://github.com/antonputra
=========
⏱️TIMESTAMPS⏱️
0:00 Intro
0:27 Recover key using another EC2
6:45 Recover key using Session Manager
=========
Source Code
📚 - Tutorial: https://antonputra.com/amazon/how-to-…
#AWS #EC2 #DevOps
Content
0 -> In this video, I'll show you how to recover
access to your EC2 instance if you lose your
4.8 -> private key. In the first example, we will do it
the old way, using the second EC2 instance and
10.48 -> attaching root volume from the original VM.
In the second example, we will use AWS Session
15.92 -> manager to directly connect to the EC2 and add
a new public key. You can also find all the
22.08 -> commands and code that I use in this video in
the blog post. The link is in the description.
27.36 -> We have a single EC2 instance in this region.
You can find the key pair name, which is old-key.
35.28 -> Let's pretend that we somehow lost the private
key and are not able to log in to this VM.
41.36 -> The first approach will use a second
EC2 instance to recover access.
45.84 -> First of all, we need to create another key pair
and store its private key in a secure place.
51.52 -> You can keep it in one of the password managers,
54.48 -> such as LastPass. Give it a name, new-key.
Next, we need to get information about the
60.32 -> original instance and its root volume. Write
it down somewhere; we would need it later.
65.6 -> From the Details tab, we need to
get the instance ID and AMI ID.
70.32 -> We are going to use this AMI ID to create an EC2.
73.76 -> In some cases, you would need to create an AMI
image yourself. You can do it from the console,
78.72 -> click Actions, image and
templates and create image.
82.48 -> From the Networking tab, you need to
find the Availability zone. The new
86.64 -> instance that we're going to create has to be
placed in the same AZ to attach the volume.
91.76 -> Finally, on the Storage tab, you need to take
a note of the Root device name and a Volume ID.
97.76 -> We're going to detach this volume
from the original instance and
101.52 -> connect it to a new one. When we recover the key,
104.56 -> we would need to attach this volume back
and use exactly the same device name.
109.92 -> Now, when you have all the
information, you can stop the instance.
113.52 -> If you used Auto-assign IP address on
launch and not Elastic IP, most likely,
118.64 -> it will be released. When you start this instance
again, you will get a new public IP address.
124.88 -> The next step is to launch a temporary instance.
129.68 -> Let's call it recover-my-server.
Use the same AMI ID for your image.
137.2 -> Select the new-key pair. You also need to
place it in the same subnet public-us-east-1a.
144.16 -> Make sure that Auto-assign public IP is
enabled and select the same security group
149.68 -> that you used for the original instance.
Also, take a note of the new instance ID.
156.88 -> Now, we need to detach the root
volume from the original instance and
160.96 -> attach it to the temporary instance.
If you launched your original instance
173.6 -> from an AWS Marketplace AMI, and your
volume contains AWS Marketplace codes,
179.76 -> you must first stop the temporary
instance before you can attach the volume.
187.28 -> Make a note of the device name. We're going
to mount it to the temporary directory.
193.2 -> The next step is to add the new public key
to authorized_keys on the original volume
198.72 -> mounted to the temporary instance.
200.8 -> If you just created new-key pair as I
did, you need to update permissions.
206.24 -> You can get the public IP from the console,
then use it to SSH to the temporary instance.
220.48 -> From the temporary EC2, mount the volume that
you attached to the instance so that you can
225.84 -> access its file system. The device name
might appear differently on your instance.
231.36 -> You can check the name with the following command.
In my case, I need to mount the xvdf1
237.12 -> partition to the temp folder.
Let's create that temporary folder first.
245.12 -> If you use Amazon Linux, Ubuntu, or
Debian as your temporary instance,
249.84 -> use the following command to mount partition.
252.24 -> If you have Amazon Linux 2, CentOS, SUSE
Linux 12, or RHEL 7.x, use this command.
258.64 -> If you get an error stating
that the file system is corrupt,
262.32 -> run the following command to use the fsck utility
to check the file system and repair any issue.
269.84 -> From the temporary instance,
only if you use Ubuntu,
272.96 -> use the following command to update
authorized_keys on the mounted
276.4 -> volume with the new public key from the
authorized_keys for the temporary instance.
281.2 -> The following examples use the Ubuntu user
name ubuntu. You might need to substitute
286.72 -> a different user name, such as
ec2-user, for Amazon Linux instances.
291.52 -> If this copy succeeds, you
can go to the next step.
294.64 -> Otherwise, if you don't have permission to edit
files in /mnt/tempvol, you must update the file
300.48 -> using sudo and then check the permissions on
the file to verify that you are able to log
306.4 -> into the original instance. Use the following
command to check the permissions on the file.
311.76 -> In this example output, ubuntu is
the user and ubuntu is the group.
317.12 -> Next, use sudo to re-run the
copy command that failed.
320.88 -> Then update ownership to
the original ubuntu:ubuntu.
325.68 -> From the temporary instance, unmount the volume
that you attached so that you can reattach it
330.96 -> to the original instance. For example,
use the following command to unmount the
335.84 -> volume at /mnt/tempvol.
Then Detach volume.
350.32 -> Reattach the volume to the original instance.
With the volume still selected, choose Actions,
357.04 -> Attach Volume. Select the instance ID of
the original instance, specify the device
362.4 -> name that you noted earlier for the original
root device attachment and then choose Attach.
368.48 -> If you don't specify the same device name as
the original attachment, you cannot start the
373.92 -> original instance. Amazon EC2 expects the
root device volume at sda1 or /dev/xvda.
382.08 -> Start the instance and grab
a new public IP address.
395.28 -> Now you can use the new-key to
SSH to the original instance.
405.68 -> In the second part, I'll show you how
to recover access to your original
409.68 -> instance using AWS Session Manager.
412.32 -> In my opinion, it's the best and most
convenient way, not even to say that
416.56 -> it can completely remove the need from
using key pairs again in the future.
421.44 -> Create an IAM role for your instance that
would grant access to Session Manager.
425.84 -> Call it my-server-role and attach
AmazonSSMManagedInstanceCore policy to the role.
437.12 -> If you already have the IAM role or
sometimes called Instance profile,
441.2 -> you can simply add that policy
to the existing role. Otherwise,
445.28 -> let's modify the EC2 instance to use this profile.
Go to Actions, Security, and Modify IAM role.
468.48 -> Then you can navigate to AWS Systems Manager.
474.88 -> Click Start session under
the Session manager pane.
478.88 -> It may take 5 to 10 minutes for
your EC2 instance to show up there;
483.52 -> just be patient. The last time when I
tested, it took more than 30 minutes.
492.88 -> Now, let's create a new key
pair and call it new-key-2.
511.44 -> To extract the public key from the
key pair, use the following commands.
525.52 -> On the original VM, you can simply add the
additional public key to the authorized_keys.
532.24 -> One key per line, or you can replace the old one.
535.68 -> If you used Amazon Linux,
replace ubuntu with ec2-user.
539.92 -> Press o and add a new public key with a key
name new-key-2. Save and terminate the session.
559.12 -> Try to SSH with a new-key-2.
567.6 -> You should be able to log in to
your VM using the new key pair.
571.52 -> Thank you for watching, and
I'll see you in the next video.
Source: https://www.youtube.com/watch?v=LzBje3xSwmQ