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: Disconnected : No supported authentication methods available (server sent :publickey)
- Incorrect .ppk file: 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
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.
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.
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.
- Download putty and puttygen, or the putty package and install it.
- Get the .pem file from your AWS EC2 instance.
- 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.
- In putty, use ec2-user@your.public.dns.that.you.get.from.aws.ec2.instance, 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.
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.
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.
For me, I just had to tell FileZilla where the private keys were:
- Select Edit > Settings from the main menu
- In the Settings dialog box, go to Connection > SFTP
- Click the "Add key file..." button
- Navigate to and then select the desired PEM file(s)
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.
- 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.
- 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.
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"
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.
来源：https://stackoverflow.com/questions/24587443/aws-disconnected-no-supported-authentication-methods-available-server-sent