"Server Refused our key" after launching instance from private EBS AMI
Solution 1
I had a similar problem with that error message and here is how I fixed it. Hope this helps you, or someone else who is stuck and finds their way here:
- In the AWS Console ensure your instance is healthy and running
- Check you have used the correct public DNS address, listed when you click on an instance
- Select Security Groups from left hand side and click on the security group you want to use
- Click the Inbound tab
- From the Create a new rule: dialog select SSH
- In source put your IP address and CIDR value. If its just you don't have a NAT on your network just use 32 as your CIDR (eg. ?.?.?.?/32)
- Click Add Rule
- Click Apply Rule Changes
- Right click on your instance and select Create Image (EBS AMI)
- Give it an Image Name in the Create Image wizard and click Create
- After a short time select AMI's from the left hand nav bar in AWS console
- Right click on the new AMI and click Launch Instance
- On the Request Instances Wizard click Continue until you have to Create Key Pair
- Choose a key pair and make note of it (NOTE: If you haven't still got your .pem file for this key pair you will need to generate a new one from selecting Key Pairs on left hand navbar, Create Key Pair etc. to obtain .pem file)
- Select security group with the rule you created for your IP address (and CIDR of 32 - no subnet mask)
- Click continue, and on the next screen click Launch
- Go back to the Instances view and wait until your Instance is fully initialized and healthy
- Open PuttyGEN
- Click Conversions from the Toolbar, and Import Key
- Navigate to your .pem key in the file browser and open it
- Select SSH-1 (RSA) from the Parameters box
- Put your key pair name in the Key comment box (just for good house keeping)
- Click Save private key and save the .ppk file somewhere on your file system
- Open Putty
- Enter the public DNS for your EC2 instance in the Host Name box
- Enter port 22
- Tick SSH radio button from the Connection Type box
- Click on SSH from the Connection tree in the left hand side nav bar
- Click on Auth
- Click Browse in the Authentication parameters box, and open your .ppk file
- Click Session from the left hand nav bar
- Enter a name for this connection in the Saved Sessions text box, and click Save (this is so you don't have to go through the putty connection set up each time, and can just double click your saved connection - for those unaware)
- Click Open
- When prompted for a login name you will probably use 'ec2-user' or 'ubuntu' (TIP: use 'root' and you will probably get a message telling you what username you should use instead!)
- No need for a password, the .ppk file will authenticate you
- Hopefully, you're now connected to the EC-2 instance and good to go!
Solution 2
I had this issue with a new SUSE instance. I was finally able to connect using user 'root'. It kept rejecting ec2-user.
Solution 3
this means that you are not using correct user name for logging into your ec2 instance. here is list of users you can use in putty to connect to ec2 instance For an Amazon Linux AMI, the user name is ec2-user. For a RHEL5 AMI, the user name is either root or ec2-user. For an Ubuntu AMI, the user name is ubuntu. For a Fedora AMI, the user name is either fedora or ec2-user. For SUSE Linux, the user name is either root or ec2-user. Otherwise, if ec2-user and root don't work, check with the AMI provider.
Solution 4
Since your AMI originates from a community AMI and not an official public AMI, it is possible that it has not been setup to copy the ssh keys on instance startup, or that it uses a different mechanism to do it.
My understanding is that for the ssh keys to be copied on startup, some shell script must be run inside the instance itself, as briefly described here.
The AMI description page mentions that it has been "cloud-init enabled", so maybe there is a way to do it through CloudInit. See the doc here.
Solution 5
I had this issue and it turned out I was typing ec2_user when it was meant to be ec2-user
Kelvin
Updated on April 26, 2021Comments
-
Kelvin about 3 years
I have created my own EBS AMI, shared it with another AWS account, launched NEW instance based on this image with NEW key-pair and now when I am trying to connect to this new instance I am getting error: "Server Refused our key".
This is what I did (step by step):
- Configured new CentOS 6.3 server in my personal account (with my personal key-pair)
- Created EBS AMI image of that server
- Shared this image with my client's account
- Launched new instance in my clients account based on this shared image + new key-pair
- New launched instance doesnt want to take new key-pair. After some testing I figure that it accepts my personal key-pair instead.
How do I make new instance from my image to accept new key-pairs? I even tried removing ".ssh/authorized_keys" file in original image, launch new instance based on this image without public key and still no success.
Please advise how to create images that would not be attached to old key-pairs
-
Kelvin almost 12 yearsOk, Thanks a lot for your help David. I will try to figure out what else can be done.
-
Mikael Call over 10 years"TIP: use 'root' and you will probably get a message telling you what username you should use instead!" - very creative!
-
s_h over 10 yearsgreat, ec2-user was the user.
-
detour about 10 yearsFound this to be a helpful answer. I chose the Ubuntu 12.04 image and had to login using the ubuntu user instead of ec2-user.
-
Joseph Casey over 9 yearsliterally the best troubleshoot steps on the internet.
-
Darius over 9 yearsYou're too kind! Glad it helped!
-
markmnl over 8 yearsI think you can remove " If its just you don't have a NAT on your network just use 32 as your CIDR (eg. ?.?.?.?/32)" that doesnt make sense - whether you are behind NAT or not it only matters what public IP you are coming from is of which there will be only one
-
markmnl over 8 yearsAlso creating the Image was just for prudence? It doesn't have anything to do with SSH does it? Otherwise, thanks!
-
Tonio Liebrand about 7 yearsam i the only one for whom this unfortun. doesnt work?
-
Shiv Singh over 6 yearsi am sure your combination is not correct or you are not using correct Key pair
-
MikeKulls almost 6 yearsThis was actually the correct answer for me, I was typing ec2_user instead of ec2-user. So the down vote is a bit harsh.
-
James over 5 yearsI keep forgetting that sometimes the user is "centos" instead of "ec2-user". This jogged my memory though.
-
James over 5 yearsIt was "centos" in my case.