PSFTP connection using key authentication

The error means that FileZilla tried all available authentication methods and have not succeeded. In your case, there was only public key authentication method available (a method that the client [FileZilla] and the server agreed on mutually).

As you claim that you have set up FileZilla correctly, chances are that you have not configured the public key on server-side.

For instructions see:

• https://winscp.net/eng/docs/guide_public_key or
• https://www.howtoforge.com/how-to-configure-ssh-keys-authentication-with-putty-and-linux-server-in-5-quick-steps and
• Disconnected: no supported authentication methods available

Though actually all the guides expect that you have a way to connect (e.g. password authentication). What does not seem to be the case. Possibly your server administrator/hosting provider has its own mechanism for setting up the public key authentication.

If you specify, what is your server like, you may get more specific answers.

As of Windows 10 v1809, the default config (found in %ProgramData%/ssh/sshd_config) defines a separate AuthorizedKeysFile for administrator users:

Match Group administrators
       AuthorizedKeysFile __PROGRAMDATA__/ssh/administrators_authorized_keys

This means any user who is in the special Windows Administrators group (SID S-1-5-32-544) will not look at the %UserProfile%/.ssh/authorized_keys file but will rather look at %ProgramData%/ssh/administrators_authorized_keys.

You have a few options:

• Use a non-administrator user, or
• Comment out those two lines from the bottom of sshd_config, which will then revert back to the default per-user AuthorizedKeysFile, or
• Add your keys to the (global!) administrators_authorized_keys file

My recommendation is to use a non-admin user if possible, or modify the config otherwise. A global key that is accepted for any account in the Administrators group sounds like unnecessary complexity.¹

¹ In a default config it is always possible to impersonate any other user from an admin user, since an admin user generally implies full root-level control in Windows. That might be their rationale for this default. But of course it makes configuration of a multi-user system rather confusing, where some (non-admin) users have their own authorized keys in a standard location while other (admin) users must share a single nonstandard authorized key list.

I believe there are no security benefits to such a configuration, apart from making it obvious that all admins can impersonate each other.

A future release may create user-specific folders under %ProgramData/ssh.

This is somewhat explored here: https://github.com/PowerShell/Win32-OpenSSH/issues/1324