No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic) :: Support Forum

lrks
Joined:: 2022-04-12
Posts:: 3

No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic)

2022-04-13 01:41

Hi,

So I am using Fedora Server 35. On my Windows 10 PC, I am trying to use WinSCP to connect to my server via SFTP. However, I cannot seem to get it connected; I always get this message:

No supported authentication methods available (server sent: publickey,gssapi-keyex,gssapi-with-mic)

NOTE: Previously, my server was set up as Ubuntu Server but then I made the switch to Fedora Server, however, it has the same private IP. Maybe that is causing or it is related to this issue? I had no issues using WinSCP to SFTP to my Ubuntu Server.

I have configured the sshd_config file to enable all the GSSAPI options to no prevail.
I generated a new PuTTY key via WinSCP and uploaded the public key to my server and that did not work.
I enabled PasswordAuthentication and that worked fine.
I have deleted the existing PPK key and created a new one.
I have cleared the cache.
I uninstalled and reinstalled WinSCP.

So I tried to SFTP to my server via PowerShell and it worked. I can also use FileZilla with no issues, but I would much rather use WinSCP; it's cleaner and easier to use.

WinSCP does not authenticate for some reason that is unknown to me. I tried out CyberDuck and that did not work either.

Do I need to have a certain sshd_config configuration on my server or a package installed on my server to accept WinSCP?

Session_Logs.txt (22.28 KB)

Reply with quote

lrks
Joined:: 2022-04-12
Posts:: 3

Solved

2022-04-13 02:31

After sifting through about one hundred articles, I found the answer for Fedora, my particular OS. Someone had the same issue I was having with the same OS.

Turns out that:

Fedora 33 and above no longer allow ssh-rsa authentication using a SHA1 message digest, due to security concerns. ssh-rsa keys are fine and can still be used, but the SSH client needs to use them with a newer SHA2-based authentication handshake.

The person's suggestion was to use either EdDSA or ECDSA.

It works now!

Reply with quote