amazon-web-services how - Change key pair for ec2 instance
ec2-fingerprint-key format (12)
I have tried below steps and it worked without stopping the instance. My requirement was - as I have changed my client machine, the old .pem file was not allowing me to log in to the ec2 instance.
- Log in to the ec2 instance using your old .pem file from the old machine. Open ~/.ssh/authorized_keys
You will see your old keys in that file.
ssh-keygen -f YOUR_PEM_FILE.pem -y It will generate a key. Append the key to ~/.ssh/authorized_keys opened in step#1. No need to delete the old key.
From AWS console, create a new key pair. Store it in your new machine. Rename it to the old pem file - reason is old pem file is still associated with the ec2 instance in AWS.
I am able to log in to the AWS ec2 from my new client machine.
How do I change the key pair for my ec2 instance in AWS management console? I can stop the instance, I can create new key pair, but I don't see any link to modify the instance's key pair.
Once an instance has been started, there is no way to change the keypair associated with the instance at a meta data level, but you can change what ssh key you use to connect to the instance.
There is a startup process on most AMIs that downloads the public ssh key and installs it in a .ssh/authorized_keys file so that you can ssh in as that user using the corresponding private ssh key.
If you want to change what ssh key you use to access an instance, you will want to edit the authorized_keys file on the instance itself and convert to your new ssh public key.
The authorized_keys file is under the .ssh subdirectory under the home directory of the user you are logging in as. Depending on the AMI you are running, it might be in one of:
/home/ec2-user/.ssh/authorized_keys /home/ubuntu/.ssh/authorized_keys /root/.ssh/authorized_keys
After editing an authorized_keys file, always use a different terminal to confirm that you are able to ssh in to the instance before you disconnect from the session you are using to edit the file. You don't want to make a mistake and lock yourself out of the instance entirely.
While you're thinking about ssh keypairs on EC2, I recommend uploading your own personal ssh public key to EC2 instead of having Amazon generate the keypair for you.
Here's an article I wrote about this:
Uploading Personal ssh Keys to Amazon EC2
This would only apply to new instances you run.
Yegor256's answer worked for me, but I thought I would just add some comments to help out those who are not so good at mounting drives(like me!):
Amazon gives you a choice of what you want to name the volume when you attach it. You have use a name in the range from /dev/sda - /dev/sdp The newer versions of Ubuntu will then rename what you put in there to /dev/xvd(x) or something to that effect.
So for me, I chose /dev/sdp as name the mount name in AWS, then I logged into the server, and discovered that Ubuntu had renamed my volume to /dev/xvdp1). I then had to mount the drive - for me I had to do it like this:
mount -t ext4 xvdp1 /mnt/tmp
After jumping through all those hoops I could access my files at /mnt/tmp
Run this command after you download your AWS pem.
ssh-keygen -f YOURKEY.pem -y
Then dump the output into
Or copy pem file to your AWS instance and execute following commands
chmod 600 YOURKEY.pem
ssh-keygen -f YOURKEY.pem -y >> ~/.ssh/authorized_keys
Modifying the answer from "yegor256". As if below steps are followed it will save lot of time and there will be no need to stop the running instance.
- Start new t1.micro EC2 instance, using new key pair. Make sure you create it in the same subnet, otherwise you will have to terminate the instance and create it again.
- SSH to the new micro instance and copy content of ~/.ssh/authorized_keys somewhere on your computer.
- Login to main instance with old ssh key.
- Copy & replace the file content from point 2 to ~/.ssh/authorized_keys
- Now you can login again only with new key. Old key will not work anymore.
That is it. Enjoy :)
In case you are using ElasticBeanstalk platform, you can change the keys by going:
- Elastic Beanstalk panel
- Instances (cog top-right)
- EC2 key pair
This will terminate current instance and creates new one with chosen keys/settings.
The simplest solution is to copy the contents of
into your AWS instance's authorized_keys at
This will allow you to ssh into the EC2 instance without specifying a pem file for the ssh command. You can remove all other keys once you've tested connecting to it.
If you need to create a new key to share it with someone else, you can do that with:
ssh-keygen -t rsa
which will create the private key.pem file, and you can get the public key of that with:
ssh-keygen -f private_key.pem -y > public_key.pub
Anyone who has public_key.pub will be able to connect with
ssh [email protected] -i public_key.pub
This will work only if you have access to the instance you want to change/add the key in. You can create a new key pair. Or if you already have the key pair, then you can paste the public key of the new pair in the authorized_keys file on your instance.
Now you can use the private key for that pair and log in.
Hope this helps.
I went through this approach, and after some time, was able to make it work. The lack of actual commands made it tough, but I figured it out. HOWEVER - much easier approach was found and tested shortly after:
- Save your instance as an AMI (reboot or not, I suggest reboot). This will only work if EBS backed.
- Then, simply start an instance from this AMI and assign your new Keyfile.
- Move over your elastic IP (if applicable) to your new instance, and you are done.
I believe the simpliest aproach is to :
- Create AMI image of original iinstance.
- Launch new EC2 instance using AMI image (from step 1) with new key pair.
- Login to new EC2 instance with new key.
Here is what I did, thanks to Eric Hammond's blog post:
- Stop the running EC2 instance
- Detach its
/dev/xvda1volume (let's call it volume A) - see here
- Start new t1.micro EC2 instance, using my new key pair. Make sure you create it in the same subnet, otherwise you will have to terminate the instance and create it again. - see here
- Attach volume A to the new micro instance, as
SSH to the new micro instance and mount volume A to
$ sudo mount /dev/xvdf1 /mnt/tmp
- Terminate micro instance
- Detach volume A from it
- Attach volume A back to the main instance as
- Start the main instance
- Login as before, using your new
I'm just starting to use EC2 myself so not an expert, but Amazon's own documentation says:
we recommend that you use the local instance store for temporary data and, for data requiring a higher level of durability, we recommend using Amazon EBS volumes or backing up the data to Amazon S3.
I do more data analysis than web hosting, so persistence doesn't matter as much to me as it might for a web site. Given the distinction made by Amazon itself, I wouldn't assume that EBS is right for everyone.
I'll try to remember to weigh in again after I've used both.