Please help me! After reboot my ec2 server, I cannot connect to new AWS EC2 instance via SSH clients
Just print
'Permission denied (publickey).'
I googled really hard. Most people said that it is about problem of username. 3 hours ago, I used 'ec2-user' as my username. Just minutes ago, I also used username 'ec2-user'. But, after reboot my ec2 server I cannot connect with my username 'ec2-user'. What the hell?
Please help me T.T
User: tried "root" and also "ec2-user", "admin" but still I cannot connect
Using .pem keypair that AWS generated and I downloaded
Confirmed security group and Key Pair Name on instance
Instance: ec2-52-78-40-153.ap-northeast-2.compute.amazonaws.com
AMI ID: amzn-ami-hvm-2016.09.0.20161028-x86_64-gp2 (ami-983ce8f6)
OS: OS X el capitan
The fact that you are receiving Permission denied (publickey) means that you have correct network connectivity to your instance and the Security Group is permitting SSH traffic. Therefore, the problem lies with authentication.
Some things to check:
Use ssh -v to turn on verbose debug information
Select the instance in the Amazon EC2 Management Console and look for the Key Pair name. Confirm that it matches the name of the file you are using. (The filename itself is irrelevant, but will be accurate unless files were renamed.)
If you have added/modified users on the instance, you might need to use a different username. If you have not changed users, then ec2-user is the correct username.
If you are unable to connect, then you can follow the directions from pages such as:
How to Recover an Unreachable Linux Instance
Recovering a corrupted EC2 instance
Replace a lost Key Pair on an EC2 instance
Basically, the steps are:
Stop the instance
Detach the boot volume (remember the device identifier, eg /dev/sdf)
Attach the instance to another Amazon EC2 Linux instance
Navigate to the /home/ec2-user/.ssh directory and confirm that the correct public key is inserted into the authorized_keys file. If desired, create a new keypair and put the public key in that file.
Detach the volume
Reattach the volume to the original instance
Start the original instance and attempt to login
Basically, Linux will check the .ssh/authorized_keys file in the home directory of the user being logged-in. If additional users have been created, put their keys in the same location within their home directories.
Related
Yesterday I downloaded Filezilla, after the downloading, I got warn message from my computer, and when I checked the download folder, all data were deleted including putty key and .PPM file. could anyone explain me please, how can I recover these files?
Once you download an AWS pem you can never redownload it again (this is for security purposes if your account was compromised).
Best practice would be store anything of value in an external storage, rather than on a single users machine.
Unfortunately as it stands the instances will not be connectable over SSH without having a PEM. This isn't to say you have lost access to these instances however.
If the individual host is not of importance or can be recreated very easily, you could simply create a new SSH key within AWS and launch new instances using this configuration. You can always create an AMI of the current instances to launch ew one that is identical but specify your new SSH key when you launch.
If the hosts are important AWS support to allow you access the host via a terminal. Before accessing generate a new private/public key and then add the public key to the hosts .ssh/authorized_keys file once you have gained access.
The simplest solution would be to use Sessions Manager to allow you to access the host either via the console or the CLI.
For sessions manager the instances IAM role will need to grant permissions as well as the agent being previously installed.
My AWS account was suspended when my credit card expired and I updated the card in an hour. The access to my account was restored. But when I started my EC2 server, and tried to connect with SSH it gave an error saying Key not recognised.
I tried to follow the steps provided by AWS support to attach my volume to another server, reset the SSH permissions and re-attach volume to my original server. But on attaching volume to new server and mounting it, I found that the user directory (/home/ubuntu) was missing along with the /var/www directory from apache 2. So I have been unable to reset the SSH access.
Can anyone help with this?
Currently, I am facing an issue related to AWS. A project is already uploaded on AWS server and always connect to that Project by using PEM key of that particular project. But from last week I am not able to connect with the AWS server by using the PEM key. I got one solution for this, as by creating new instance i will be able to got my access on the project but this will make me lose of my whole data & database as a result. Is this occurred due to virus or any thing else? Got stuck over here badly. Any help will be appreciable.
I think the authorized_keys file has some incorrect entries. Let's remove the key from the file and add it again.
remove the host key
ssh-keygen -R [hostname]
ssh again
ssh -Tv ec2-user#example.com -i ~/mykey.pem
In order to use existing EBS volume with data in a new ec2, with a new ssh key:
Create a snapshot of the current instance's EBS, and create a volume.
Create a new instance with a new ssh key.
Stop the new instance and attached the previously created volume as the boot volume.
Start the new instance and you should be able to login with the new ssh key.
The log indicates that you do not have any networking issues. It is the ssh server on the instance that is rejecting your connection.
The first thing to confirm is that you are connecting to the correct Amazon EC2 instance. If an EC2 instance is stopped and started again, it might change public IP address (depending how it is configured). Therefore, make sure that you are connecting to the right instance.
Next, confirm that you are using the correct username. You are using ubuntu#, which is correct if the instance is using an Ubuntu AMI. However, it is possible to create additional users on a Linux computer and the PEM files are associated with specific users. Therefore, confirm that this is the correct username for use with that PEM file.
Next, confirm that you are using the correct PEM file. The PEM file should contain the private half of a keypair that matches the public half that is stored on the instance in the user's ~.ssh/authorized_keys file. The log indicates that the instance is rejecting the provided keypair. Therefore, you might be using the wrong one.
Failing all this, there are some recommended steps available on: Walkthrough: Reset Passwords and SSH Keys on Amazon EC2 Instances - AWS Systems Manager
However, they might not work since you are using an Ubuntu instance, which might not have standard AWS software installed.
Let us know how you go!
I lost the PEM key to the EC2 Instance.
I followed all the following steps:
HOW TO ACCESS EC2 INSTANCE EVEN IF PEM FILE IS LOST
Accessing the EC2 instance even if you loose the pem file is rather easy.
First, create a new instance by creating new access file, call it 'helper' instance with same region and VPC as of the lost pem file instance.
Now stop the lost pem file instance. Remember not to terminate instance but to stop it.
Go to EBS volumes, select the root volume of the lost pem file instance and detach.
Now again select the detached volume and this time you have to attach this volume to helper instance which we created before. Since helper instance already has a root volume by default as /dev/sda1, the newly attached volume will be secondary(eg: /dev/sdf).
Login to your helper instance with its pem file.
Execute below commands:
# mount /dev/xvdf1 /mnt
# cp /root/.ssh/authorized_keys /mnt/root/.ssh/
# umount /mnt
Detach the secondary volume from helper instance.
Again attach the volume back to our recovery instance. Start the instance. Terminate the helper instance.
Use helper instance pem file to log into recovery instance.
Great to see your answers. Just for the information AWS has shared their official tutorial also for the same hence sharing the same here: https://youtu.be/F8jXE-_hdfg
With this video we can found, AWS support has been getting this same questions from the users and hence made this stuff with detailed structure.
This is with step by step details. Hope this helps.
A few weeks ago AWS announced SSM Session Manager. This allows you to access (login) to your EC2 instances without requiring a key pair, password, open ports, etc. Both Windows and Linux are supported.
The latest AMIs do not have the latest version of the SSM agent. You will need to update that first, which you can also do via the SSM Console or via AWS CLI.
AWS Systems Manager Session Manager
Once you connect to your system, you can then correct any problems that you have. For example, you could create a new keypair in the AWS Console and then copy the public key to `~/.ssh/authorized_keys so that you can once again access your system via SSH.
For Windows systems, you can even change the Administrator password if it has been forgotten. This can be a lifesaver.
In my case auto-scaling group was enabled so it became easy to attach instance to new Key Pair, Here are the steps that I followed
Created new Key pair under EC2 Dashboard -> Key Pairs (download the .pem file in this step)
Go to Auto Scaling -> Launch Configurations
Select required Launch Configuration and then copy launch configuration
Here while reviewing launch configuration you can create a new key pair or you can select the existing key pair that is created at step 1
Once new launch configuration is created go to the auto-scaling group
Select the auto-scaling group then select new launch configuration from the dropdown
Once this is done if you stop the auto-scaling group instance it will create a new one with the new launch configuration (with new key pair)
List item
here are the steps to access EC2 instance on the fly after loss of key pair
Create new instance in same region with new key pair and name it as TEST
now connect to the new instance and copy the data from authorized_keys from .ssh directory (/.ssh/authorized_keys)
go to the security group of lost pem file instance and allow ssh for EC2 instance connect
(please check the ip range for specific region by command curl -s https://ip-ranges.amazonaws.com/ip-ranges.json| jq -r '.prefixes[] | select(.region=="us-east-1") | select(.service=="EC2_INSTANCE_CONNECT") | .ip_prefix')
Once you done with the security group changes connect to the lost file instance by EC2 instance connect
Now open .ssh/authorized_keys and replace it by TEST instance authorized_keys
you can now access your lost key file instance by new key pair
terminate TEST instance and do changes in security group.
Take a note that this solution might expose port 22 of your instance for while.
Thank you.
I need to share an ami so that it can be used by a client to create their own instances through their own account. However, I do not wish that client to be able to ssh in to the instance. I will need to be able to ssh into the instance to be able to maintain it. They will have ftp and www access only. I've got the ftp and www access part working through ssh configuration. How do I keep them out of ssh when they are starting up the instance with their own keypairs?
Well, you can't really prevent this, if they are determined to get in, since they control the instance.
Stop instance → unmount root EBS volume → mount elsewhere → modify contents → unmount → remount → restart → pwn3d.
However, according to the documentation, if you don't configure the AMI to load their public key, it just sits there and doesn't actually work for them.
Amazon EC2 allows users to specify a public-private key pair name when launching an instance. When a valid key pair name is provided to the RunInstances API call (or through the command line API tools), the public key (the portion of the key pair that Amazon EC2 retains on the server after a call to CreateKeyPair or ImportKeyPair) is made available to the instance through an HTTP query against the instance metadata.
To log in through SSH, your AMI must retrieve the key value at boot and append it to /root/.ssh/authorized_keys (or the equivalent for any other user account on the AMI). Users can launch instances of your AMI with a key pair and log in without requiring a root password.
If you don't fetch the key and append it, as described, it doesn't appear that their key, just by virtue of being "assigned" to the instance, will actually give them any access to the instance.
I was able to finally accomplish this crazy task by using this process:
1) Login as ubuntu
2) create a user, belongs to sudo and admin group
3) install all my s/w under the newuser
4) verify that new user has all required privileges
5) chroot jail the ubuntu user to ftp access only
when the ami is transmitted to the new zone/account, the ubuntu user exists as a sudoer, but cannot ssh into the instance. Ftp allows them to connect to the system, but they view a bare directory and cannot cd anywhere else in the system.
It's not a complete denial, but I think it will serve the purpose for this client.