Recovering a corrupted EC2 instance

Amazon Web Services is one of the most popular cloud service providers. I am a customer of Amazon. I like the services provided by Amazon very much. Compared to other cloud service providers AWS is simple, secure and advanced. I use EC2 machines for my project related activities as well as my personal experiments. Since I mostly work on open source software, 99.99 % of my EC2 instances are Linux instances. The only way to access these instances is through ssh. I use putty as the ssh client. If something happens to the ssh server, we will not be able to access the server. Sometimes the ssh server crashes due to overload. This can be resolved by rebooting the instance.

Sometimes because of wrong configs in the sshd config file, the ssh server may stop. The ssh server will not start until we make that file proper and restart the service. But for making these changes we have to access the machine.

By default we don’t have direct root login into the machine. We usually login to one user which is a sudo user and using sudo privileges, we access the root. If something happens to the sudoers file or if some wrong entry made in sudoers file, the root access will be revoked.

These are some of the commonly occurred situations where users loose access or super user privilege in the ec2 machine. Most of the users terminate and leave the instance in this situation.

If the instance is an EBS backed instance, we don’t have to terminate and leave the machines in this kind of situations. We can recover these instances. It is simple and can be done in few steps. If the instance is with ephemeral storage, we cannot do anything, because shutting down will clear all the data in the instance.

  1. Start a new instance in the same availability zone as that of the EBS of the broken machine. Micro or nano instance type is fine. If you already have an instance, no need of this instance.
  2. Stop the broken machine. Note down the mount locations
  3. Detach the EBS from the instance.
  4. Attach the EBS to the second EC2 instance (The newly launched one)
  5. Mount the EBS to some directory in the second EC2 instance.
  6. Navigate through the files and directories and make the required changes.
  7. Unmount the EBS
  8. Detach the EBS from the second instance
  9. Attach the EBS to the first instance
  10. Use the same mount location as that of the orginal
  11. Start the instance.

This should fix the problem.

Creating Private key in PPK using Private Key in PEM

When we create Amazon instances, we will get key as .pem file. But for logging in to the instances directly using putty, we need the private key in .ppk format.
For creating the private key in ppk, we need puttygen. Puttygen is available with the full bundle of putty. The steps are mentioned below.

1) Be ready with the private key in .pem format

2) Open the Puttygen and click on the top left option File and import the private key in .pem format.

3) Then it will be opened.

4) Choose a passphrase if required (optional)

5) Click on save private key option and save it as .ppk format.




Accessing Unix Server through Putty using Private Key

Type hostname or ipaddress


Then in the left side part of putty, click on SSH and expand.


Then you can see a section auth

Click on auth


There you will get a window with browse button.


Load your private key file (.ppk) and press open.

Then enter username and passphrase-key (if given) and login

This is the method we usually use to login to unix  cloud instances .

Creating a Public and Private Key using PuttyGen

On a Windows machine, you can use PuttyGen to generate a public/private key pair.

PuttyGen can be downloaded from

The private key is what you need on the client machine – for use with Putty for example. The public key goes to the host machine.

Open PuTTY Key Generator (puttygen.exe in the putty folder) which should look something like this.


PuTTYGen supports 3 key types:

  1. SSH-1 (RSA),
  2. SSH-2 RSA, and
  3. SSH-2 DSA

SSH-2 contains more features than SSH-1. SSH-1 has some design flaws which make it more vulnerable than SSH-2. Only choose SSH-1 if the server/client you want to connect to does not support SSH-2. The default SSH-2 RSA is probably better than SSH-2 DSA.

The Number of bits in a genereted key sets the size of your key, and thus the security level. For SSH-2 RSA, it’s recommended to set this at a minimum of 2048. PuTTYGen defaults to 1024. Setting this to 4096 would provide an even stronger key, but is probably overkill for most uses.


Click Generate to start the key generation. You will see something like the figure below ( move your mouse as suggested above the progress bar):


The result of the key generation is shown below. (in the box labelled Public key for pasting into OpenSSH authorized_keys file).


The Key comment enables you to generate multiple keys and easily tell them apart. It’s general recommended to set this to username@hostname, where the username is the username used for login, and hostname is, as it says on the tin, the name of the host machine. For example, for a user ‘amal’ on domain ‘’, set this to

The Key passphrase is an additional way to protect your private key, and is never transmitted over the internet. The strength of your key is not affected by the passphrase in any way. If you set one, you will be asked for it before any connection is made via SSH . Setting it might gain you a few extra moments if your key falls into the wrong hands, as the culprit tries to guess your passphrase. Obviously if your passphrase is weak, it rather defeats the purpose of having it.

If you don’t want the passphrase key, you can leave it empty.

Note that if your set a passphrase and forget it, there is no way to recover it. When you reload a previously saved private key (using the Load button), you will be asked for the passphrase if one is set.

Here is what PuTTYGen looks like after editing the key comment and the passphrase.


Now save your keys – one private and one public – using the Save private key and Save public key buttons respectively. You can save the public key in any format – *.txt is good. The private key is saved in PuTTY’s format – *.PPK. PuTTY will need this private key for authentication.



The public key in the highlighted box is all in one line as expected by OpenSSH, and is in the correct format (unlike the version you just saved). If you are using OpenSSH, this is what you paste in your .ssh/authorized_keys file.