SSH – Troubleshooting Key-Based Authentication Failures

rsassh

I have an RSA key pair set up for authentication into my SSH server. The server is an Ubuntu Server, and I'm trying to log in using Putty on Windows. I load my private key into Pageant (the Putty authentication agent), and I attempt to log in. The server asks for my username, which I input. Then, I receive the error message:
"Disconnected: no supported authentication methods available".

Next I tried sitting at my server machine and logging in directly with my username and password. Then, while still logged in to the host machine, I try to SSH into the server from the remote machine using the RSA key again. In this case, the login process works.

Can anyone please help me figure out why the key-based authentication only works if the user is already logged in to the host machine. Thank you.

Best Answer

I've seen this happen when the user's home directory isn't local, but on an NFS automount on the network. If your home directory isn't already mounted when sshd goes to look for your ~/.ssh/authorized_keys, it won't be able to access it in time, so public-key-based authentication will fail.

Related Solutions

Windows SSH – Fix Key Based Authentication Refusal

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

Best Answer

Related Solutions

Windows SSH – Fix Key Based Authentication Refusal

Related Question