When I login via ssh with -v I see that ssh is authenticating the following way

debug1: Authentications that can continue: publickey,gssapi-with-mic,password,hostbased

I would like to change the order ...any idea how?

My bigger problem is that user with locked accounts, can still login via public-keys. I have found that I could add the user to a group "ssh-locked" add deny that group from sshing, but I am still wondering if there is a way to tell ssh'd: Please check password before keys...

  • 1
    I think you're approaching this the wrong way - keys are (usually) more secure than passwords. If the account is locked, you need to tell the sshd daemon to not let the user login regardless of the authentication method. – EightBitTony Jun 24 '11 at 7:58
  • Like I said, I found a solution, via DenyGroups. I am asking it for the sake of interest. – Oz123 Jun 24 '11 at 7:59

The ssh server decides which authentication options it allows, the ssh client can be configured to decide in which order to try them.

The ssh client uses the PreferredAuthentications option in the ssh config file to determine this.

             Specifies the order in which the client should try protocol 2 authentication methods.  This allows a client to prefer
             one method (e.g. keyboard-interactive) over another method (e.g. password).  The default is:


I don't believe it's possible, without playing with the source, to tell the OpenSSH server to prefer a certain order - if you think about it, it doesn't quite make sense anyway.

  • If you are using Git Bash for Windows, save your ssh config to ~/.ssh/config – Spencer Williams Jan 13 '15 at 22:31
  • The order can make sense if one method depends on a previous one. For example 2FA under keyboard-interactive might depend on the user having first provided a valid password. – steveayre Sep 25 '18 at 22:42

Adding this:

PreferredAuthentications keyboard-interactive,password,publickey,hostbased,gssapi-with-mic

...to my /etc/ssh/ssh_config helped me to solve this, and saved a lot of time too!

You can check if it works by using ssh -v user@host command to connect, where -v stands for "verbose".

  • 1
    Ensure that you're adding this to the correct file ssh_config and not sshd_config. The latter will cause your ssh to fail! – Oranges13 Dec 16 '16 at 3:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.