OpenSSH server reporting conflicting authentication methods

Question

We're having problems connecting to a server using a password over SSH. What makes the situation strange is that I see contradictory authentication methods available:

$ ssh -v [email protected] -o PreferredAuthentications=password
OpenSSH_7.9p1, OpenSSL 1.1.1a  20 Nov 2018
debug1: Connecting to example.com [1.2.3.4] port 22.
debug1: Connection established.
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
[...]
debug1: Authentications that can continue: publickey,password <<< HERE
debug1: Next authentication method: password
[email protected]'s password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
[email protected]'s password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
[email protected]'s password:
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey). <<< HERE

My understanding is that the two marked lines should show matching authentication methods, so either

debug1: Authentications that can continue: publickey
[...]
[email protected]: Permission denied (publickey).

or

debug1: Authentications that can continue: publickey,password
[...]
[email protected]: Permission denied (publickey,password).

See for example other logs with matching authentication methods here, here, and here.

Is this a sign that something is wrong, or a harmless variation?

---

Edit:

1: I'm not looking for help on how to setup the authentication methods on sshd_config, this has already been done.

2: This is probably not caused by entering a wrong password, because I just tested on a personal server and the methods still match:

$ ssh -v [email protected] -o PreferredAuthentications=password
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password <<< HERE
debug1: Next authentication method: password
[email protected]'s password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
[email protected]'s password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
[email protected]'s password:
debug1: Authentications that can continue: publickey,password
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey,password). <<< HERE

3: It's also not an incorrect username, or the -o PreferredAuthentications=password flag, my personal server still replies with Permission denied (publickey,password). on those scenarios.

Answer 1

I think what's happening in your debug is that after your permitted attempts to authenticate fail, the server or your client are telling you that no more password attempts will be permitted and that the client must try the public key instead.

So, either your username or password were entered improperly (or the user is not permitted to SSH). Additionally, it did not like your public key at the end. If this issue persists and you believe that you are entering the correct credentials- you may either:

1. Have hit the limit of Authentication requests.
2. Have a misconfigured permission on your server. Please refer to the standard SSH file permissions listed in Nicolas Carey's answer here.

To solve the first issue, you will need to restart your sshd process on the server AND correct your .ssh directories permissions (along with authorized_keys in particular).

Answer 2

We have 6 known methods for ssh.

**Password authentication:** Client will ask you to enter a password, will encrypt it and use it to authenticate itself to a server.
**Public key authentication:** Each client uses a key pair to authenticate itself to a server. Server should find the key in the list of allowed keys.
**Host based authentication:** This method is similar to public key authentication, but client should not only use correct key, but also must connect from correct host.
**Keyboard authentication:** Server will use client to present zero or more prompts to client PC operator and request answers from operator.
**Challenge Response Authentication:** Used to configure keyboard authentication. You should use specific backend send the challenges and check the responses.
**GSSAPI Authentication:** GSSAPI is a IETF standard for strong encrypted authentication. OpenSSH uses GSSAPI and kerberos 5 code to authenticate clients.

Now in sshd_config config decide which is acceptable.

$ egrep ^'PasswordAuthentication|PubkeyAuthentication' /etc/ssh/sshd_config
PasswordAuthentication yes
PubkeyAuthentication yes

Now below lines show what is acceptable by server.

debug1: Authentications that can continue: publickey,password

This line shows what is accepted before these lines.

debug1: Next authentication method: publickey #After this section.
debug1: Authentication succeeded (publickey,password)

So in your case I guess as supported methods are publickey and password but you are passing PreferredAuthentications=password it is tried first and failed, After that fallback applied as publickey is also an enabled option.

So my guess is you may see expected result if don't add PreferredAuthentications option. You might be seeing unexpected debug output because of fallback.

Answer 3

I don't implore this as I would like to encourage users to use Publickey via SSH - You should probably look into that more.

However, if you want to just use the password method via ssh, do the following on the server you attempting to connect to:

1. sudo nano /etc/ssh/sshd_config

2. Search for PubkeyAuthentication and set the option to yes or no.

PubkeyAuthentication no

Add the line if it doesn't already exist and remove # at the beginning of the line if it exists. Set it to yes to allow public key authentication method and no to disallow.

Make sure your other authentication method such as password is enabled before disabling public key authentication method as you might completely lose remote access to your server.

3. Reload or restart SSH server service for the changes to take effect.

sudo systemctl restart sshd