AWS - Disconnected : No supported authentication methods available (server sent :publickey)

SSH to my AWS server just broke for both Putty and Filezilla. I'm making some effort for this post to be a comprehensive troubleshooting list, so if you share links to other stack overflow pages, I'll edit them into the question.

Disconnected : No supported authentication methods available (server sent :publickey)

The error is familiar from when I set up the connection almost a year ago. If you're setting up AWS SSH for the first time, these address the most common problems:

• Wrong username: https://stackoverflow.com/questions/21535907/disconnected-no-supported-authentication-methods-available-server-sent-publi
• Incorrect .ppk file: https://stackoverflow.com/questions/19096348/unable-to-connect-to-amazon-server-using-putty

However, the only thing I could think that would impact a previously working system is:

• Wrong IP: Restarting an AWS instance (or creating an image) is not guaranteed to keep the same IP address. This would obviously have to be updated in putty.

What other possibilities are there?

Solution to this one (per the accepted post below) is that for AWS EC2 all 3 of these need to have proper permissions (777 not ok for any of these). Here's one example that works:

/home/ec2-user/ - 700
/home/ec2-user/.ssh/ - 600
/home/ec2-user/.ssh/authorized_keys - 600

/var/log/secure will tell you which one is throwing an error, consult this video tutorial to get access if you're completely locked out: http://d2930476l2fsmh.cloudfront.net/LostKeypairRecoveryOfLinuxInstance.mp4

I had the same problem, by accident mistake. I'll share it here, in case someone may have made the same mistake.

Basic steps, as others described.

1. Download putty and puttygen, or the putty package and install it.
2. Get the .pem file from your AWS EC2 instance.
3. Use puttygen to convert the .pem file so that you'll have a private key --- mistake happened here. I chose "Conversions" tab from PuttyGen, and load my .pem file. After loading pem file, here DO NOT hit "Generate", instead directly "Save private key". That's the key you need. If you click Generate, you'll have a totally different pair of keys.
4. In putty, use [email protected], and load the private key at SSH/Auth

Good luck!

Comprehensive answer is here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html

Your problem can be related to incorrect login which varies depending on AMIs. Use following logins on following AMIs:

• ubuntu or root on ubuntu AMIs
• ec2-user on Amazon Linux AMI
• centos on Centos AMI
• debian or root on Debian AMIs
• ec2-user or fedora on Fedora
• ec2-user or root on: RHEL AMI, SUSE AMI, other ones.

If you are using OS:

• Windows - get PEM key from AWS website and generate PPK file using PuttyGen. Then use Putty to use the PPK (select it using left-column: Connection->SSH->Auth: Private key for authorization)
• Linux - run: ssh -i your-ssh-key.pem login@IP-or-DNS

Good luck.

There is another cause that would impact a previously working system. I re-created my instances (using AWS OpsWorks) to use Amazon Linux instead of Ubuntu, and received this error after doing so. Switching to use "ec2-user" as the username instead of "ubuntu" resolved the issue for me.

You will also receive "Disconnected : No supported authentication methods available (server sent :publickey)" when you have a correct Linux user but you haven't created the file .ssh/authorized_keys and saved the public key as indicated in Managing User Accounts on Your Linux Instance

PuTTY does not natively support the private key format (.pem) generated by Amazon EC2. PuTTY has a tool named PuTTYgen, which can convert keys to the required PuTTY format (.ppk). You must convert your private key into this format (.ppk) before attempting to connect to your instance using PuTTY.

The steps how to perform this are described here: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html

This solved the problem.

For me this error appeared immediatey after I changed the user's home directory by

sudo usermod -d var/www/html username

It can also happen because of lack of proper permission to authorized_key file in ~/.ssh. Make sure the permission of this file is 0600 and permission of ~/.ssh is 700.

Don't Generate Private key

Your problem is , when opened puttygen you are load file-from-aws.pem you are click on Generate this is wrong , just click on save private key button

in most cases, got no authentication method error when using the wrong username for logging in. But I do find something else if you still struggle with connection issue and you have tried all the options above.

I created couple Linux VM and try to reproduce such connection issue, one thing I found is, when AWS asked you name your key pair, DO NOT user blank space (" ") and dot (".") in key pair name, even AWS actually allow you to do so.

ex. when I named the key pair as "AWS.FREE.LINUX", connection always be refused. When I named as "AWS_FREE_LINUX", everything works fine.

Hope this will help a little bit.

Login is depending upon the AMI which you have created. Use left hand side data as a username while doing login.

ubuntu- ubuntu AMIs
ec2-user- Amazon Linux AMI
centos- Centos AMI
debian or root- Debian AMIs6
ec2-user or fedora- Fedora

In my case the problem was that the ppk file was placed in %USERPROFILE%\Downloads instead of %USERPROFILE%.ssh folder.

After I moved the file, the problem disappeared.

This: "Disconnected: No supported authentication methods available (server sent: publickey)" happened to me after I turned on Microsoft One Drive backup and sync for my files including the directory where I saved my ssh key. In my case the solution is simple: just go to Putty => SSH => Auth and just (re)browse again to where my same key is located and saved, then it worked. It looks backup and sync software such as Microsoft One Drive (and may be the same with Google Drive), affect the way Putty sees and identifies directories if the key directory is specified and then later some time installing or turning on backup and sync including that directory.

In my case the problem was with hostname/public DNS.I associated Elastice IP with my instance and then my DNS got changed. I was trying to connect with old DNS. Changing it to new solved the problem. You can check the detail by going to your instance and then clicking view details.

If you use PuTTY to connect to your instance and get either of the following errors, Error: Server refused our key or Error: No supported authentication methods available, verify that you are connecting with the appropriate user name for your AMI. Type the user name in User name in the PuTTY Configuration window.

The appropriate user names are as follows:

For Amazon Linux 2 or the Amazon Linux AMI, the user name is ec2-user.

For a CentOS AMI, the user name is centos or ec2-user.

For a Debian AMI, the user name is admin.

For a Fedora AMI, the user name is fedora or ec2-user.

For a RHEL AMI, the user name is ec2-user or root.

For a SUSE AMI, the user name is ec2-user or root.

For an Ubuntu AMI, the user name is ubuntu.

For an Oracle AMI, the user name is ec2-user.

For a Bitnami AMI, the user name is bitnami.

Otherwise, check with the AMI provider.

After an hour grinding through other suggestions and scanning every character too many times, realized I'd switched to a different user for another reason and created the .ssh and .ssh/authorized_user as the other user instead of as my new user. The owner-only 600 and 700 permissions then prevented necessary access when attempting to connect as the new user.

Simple fix below - hope sharing the story saves someone a few minutes.

$ chown mynewuser:mynewuser .ssh
$ chown mynewuser:mynewuser .ssh/authorized_keys

Based on multiple instances, if the key file and username are correct, this seems to occur when changing certain directory permissions associated with the root user.

A similar issue happened with me today. I also had searched alot about this.No one help. I just made two changes and its get working properly as well.

1. I had visited Amazon documentation where describe either Verify that there is a rule that allows traffic from your computer to port 22 (SSH) and if not present, create it and edit "Security Group" and add "SSH" to my IP. This will help.
2. In my case, In putty profile, I have to again authorize with .ppk file. I don't know why it ask again, without any changes made.

Hope it will help you.

I had the same problem, I used Public DNS instead of Public IP. It resolved now.

For me, I just had to tell FileZilla where the private keys were:

1. Select Edit > Settings from the main menu
2. In the Settings dialog box, go to Connection > SFTP
3. Click the "Add key file..." button
4. Navigate to and then select the desired PEM file(s)

I am using OpsWorks and wanted to register a new existing Linux instance from my Windows machine on AWS Cli.

Frist problem was, that I had to use my Putty generated .pkk file.

Second problem was that I needed to quote the absolute path to that .pkk file like that:

> aws opsworks register --infrastructure-class ec2 --ssh-username > ec2-user --ssh-private-key "C:\key.ppk"

This happened to me because After Load pem file to puttygen I pressed generate button and then pressed save the private key. It is not needed to press Generate button. Just Load and press Save Private Key

In order to get this to work with my AWS Linux instance, I had to change the "Type of key to generate" in PuTTYgen from "RSA" to "EdDSA" before clicking "Save private key".

I hope this helps someone else out.

I got this error when I upgraded from ubuntu 20 to ubuntu 22.

The solution was simply to upgrade my Putty to the latest version.

While trying to connect to a SiteGround server via Putty I had the same problem. Their instructions are pretty thorough, and must work for some people, but didn't work for me.

They recommend running pageant.exe, which runs in the background. You register your key(s) with Pageant, and it's supposed to let Putty know about the keys when it tries to connect.

In a couple of places I found suggestions to specify the key directly in the Putty session definition: Putty Configuration > Connection > SSH > Auth > "Private key file for authentication", then browse to your key file in .ppk format.

Doing this without running Pageant resolved the problem for me.

During ssh session my connection broke, since then I cannot ssh my SRV, I had started a new instance, and I'm able to ssh the new instance (with the same key).

I mounted the old volume to the new machine, and check the .ssh/authorized_key and couldn't find any problem with permission or content.