Monday, May 6, 2024
 Popular · Latest · Hot · Upcoming
10
rated 0 times [  10] [ 0]  / answers: 1 / hits: 6126  / 3 Years ago, sun, october 24, 2021, 2:45:12

I have been using Amazon EC2 instances in AWS. I have been successful connecting with WinSCP to a variety of instances, including Amazon Linux, Rocky Linux, SUSE, and CentOS 6, 7, and 8. All of those instances with other OSs have succeeded using a particular combination of



  • Key pair (login)

  • VPC

  • Subnet

  • Firewall (security group)


Therefore, it does not seem to be plausible that any of those choices are at fault.


In WinSCP, I can clone working WinSCP configurations from other instances and then (after adjusting the new site for the changed "Host name" and using the suggested login username of "ubuntu") I can try to connect just like I would for the others that worked. Therefore, it does not seem to be plausible that the problem is an incorrect WinSCP configuration (unless I should be using something other than "ubuntu" as the default username).


The instance is seen, but the attempt to login fails for the Ubuntu instance only.



No supported authentication methods available (server sent: publickey)



and



Using username "ubuntu".
Server refused our key.
Authentication failed.



I've looked through some of the other questions that have to do with "Server refused our key", but this isn't a problem with the key pair itself, since it works with many other instances. Nor does it seem feasible that it could be any of the other common elements that have been working for other instances. The error message itself indicates that it did see the recommended login username of "ubuntu" (and I even tried other usernames that are sometimes used for AWS instance logins such as ec2-user, admin, root, but those didn't work either).


I've also tried creating a second instance to check if there was some fluke or mistake about making the first instance, but there was no difference.


Since this failed login is for the initial login attempt to the default user, I cannot login as a different user and poke around inside or change the instance.


If it matters, I was using


Minimal Ubuntu 22.04 LTS - Jammy
https://aws.amazon.com/marketplace/pp/prodview-o5bowpuwmx3ng


UPDATE 1: The same happens for
Ubuntu 22.04 LTS - Jammy
https://aws.amazon.com/marketplace/pp/prodview-f2if34z3a4e3i


I wonder if there is something different in how Ubuntu handles the communication that requires a different setting than any other OS that has worked.


UPDATE 2: Based on a clue from the answer by rahul jain, I tried a quick test using an instance based on the previous Minimal Ubuntu LTS release.


Minimal Ubuntu 20.04 LTS - Focal
https://aws.amazon.com/marketplace/pp/prodview-meawmysinhrrs


That one worked fine. Therefore, it does seem that the issue is a change since 20.04 Focal Fossa, and it seems likely that it is related to authentication changes that require a more recent PuTTY codebase, as rahul jain suggested. I will do more testing, but the answer is looking good so far.


More From » ssh

 Answers
2

Try updating putty to the latest version i was using an older version updated it to 0.76 and it worked flawlessly
https://www.chiark.greenend.org.uk/~sgtatham/putty/


hope this helps


Eric adds:
For those like myself who are using WinSCP, the equivalent solution is to upgrade to WinSCP version 5.20 (or later). At this time, 5.20 is still in beta. (Currently the latest release is 5.19.6)


"WinSCP 5.20 is a major application update. New features and enhancements include:


...
SSH core upgraded to PuTTY 0.76. That includes support rsa-sha2-256 and rsa-sha2-512 SSH public key algorithms. ..." Excerpt from All Downloads for WinSCP.


With the help of the answer and suggestion by rahul jain, I was able to isolate the problem to WinSCP and then find this related bug report.


"Server refused our key" after updating to Ubuntu 22.04 beta on a LAMP stack


That WinSCP issue points to related issue "Bug 1952 – Support rsa-sha2-256 and rsa-sha2-512 SSH public key algorithms"


PuTTY 0.76 worked for rahul jain, likely because its SSH processing has been upgraded (e.g. version 0.75 added "Upgraded default SSH key fingerprint format to OpenSSH-style SHA-256. Upgraded private key file format to PPK3, with improved passphrase hashing and no use of SHA-1.")


The "Known Issues" in Release Notes for Ubuntu 22.04 LTS (Jammy Jellyfish) led to this related GitHub issue that describes how "openssh deprecates ssh-rsa key type ..."
Excerpt:
"It is now possible to perform chosen-prefix attacks against the
SHA-1 algorithm for less than USD$50K. For this reason, we will be
disabling the "ssh-rsa" public key signature algorithm by default in a
near-future release."


And
"Distributions are picking up on this and deprecating ssh-rsa. Fedora did this recently and it will land in the next major Fedora release. ..."


Presumably, the 22.04 release of Ubuntu has similarly deprecated the older, less secure standard for SSH authentication for similar reasons, which requires other client software to step up.


[#520] Monday, October 25, 2021, 3 Years  [reply] [flag answer]
Only authorized users can answer the question. Please sign in first, or register a free account.
olouredping

Total Points: 259
Total Questions: 100
Total Answers: 121

Location: New Caledonia
Member since Wed, Sep 15, 2021
3 Years ago
olouredping questions
Sat, Jan 14, 23, 03:36, 1 Year ago
Wed, Jan 26, 22, 22:28, 2 Years ago
Wed, Dec 7, 22, 09:02, 1 Year ago
;