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:
However, the only thing I could think that would impact a previously working system is:
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
This question is related to
amazon-web-services
ssh
putty
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
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:
If you are using OS:
ssh -i your-ssh-key.pem login@IP-or-DNS
Good luck.
I had the same problem, I used Public DNS instead of Public IP. It resolved now.
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.
Good luck!
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
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.
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.
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.
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.
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.
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.
Hope it will help you.
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.
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.
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.
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.
For me, I just had to tell FileZilla where the private keys were:
Source: Stackoverflow.com