Can someone explain the 'PasswordAuthentication' in the /etc/ssh/sshd_config file?

137,248

Solution 1

Your link points to documentation 10 years out of date.

SSH support multiple ways to authenticate users, the most common one is by asking a login and a password but you can also authenticate user a login and a public key. If you set PasswordAuthentication to no, you will no longer be able to use a login and password to authenticate and must use a login and public key instead (if PubkeyAuthentication is set to yes)

Solution 2

Please note that the PasswordAuthentication setting does not control ALL password-based authentication. ChallengeResponseAuthentication usually also asks for passwords.

PasswordAuthentication controls support for the 'password' authentication scheme defined in RFC-4252 (section 8). ChallengeResponseAuthentication controls support for the 'keyboard-interactive' authentication scheme defined in RFC-4256. The 'keyboard-interactive' authentication scheme could, in theory, ask a user any number of multi-facited questions. In practice it often asks only for the user's password.

If you want to fully disable password-based authentication, set BOTH PasswordAuthentication and ChallengeResponseAuthentication to 'no'. If you're of the belt-and-suspenders mindset, consider setting UsePAM to 'no' as well.

Public/Private Key-based authentication (enabled by the PubkeyAuthentication setting) is a separate type of authentication that does not involve sending user passwords to the server, of course.

Some would argue that using ChallengeResponseAuthentication is more secure than PasswordAuthentication because it is more difficult to automate. They therefore recommend leaving PasswordAuthentication disabled while leaving ChallengeResponseAuthentication enabled. This configuration also encourages (but does not necessarily prevent) use of publickey authentication for any automated system logins. But, since SSH is a network-based protocol, the server has no way to guarantee that responses to ChallengeResponseAuthentication (a.k.a. 'keyboard-interactive') are actually being provided by a user sitting at a keyboard so long as the challenge(s) always and only consists of asking a user for her password.

Solution 3

PasswordAuthentication is the easiest implementation, as there is nothing to do. The counter part is that you send your password, over an encrypted connection, to the server. This can be a security problem if the server has been compromised, as the password could then be capture.
With public-key, your password is not transmitted to the server, it's more secure but it needs more setup.

Solution 4

You can set it to no when using keys, or to force their use.

Share:
137,248

Related videos on Youtube

Zeta2
Author by

Zeta2

Updated on September 17, 2022

Comments

  • Zeta2
    Zeta2 almost 2 years

    On this page, the explanation given is:

    The option PasswordAuthentication specifies whether we should use password-based authentication. For strong security, this option must always be set to yes.

    But it fails to provide any use case scenarios that clarifies when a Yes or no would be appropriate. Can someone please elaborate further?

  • YumYumYum
    YumYumYum almost 10 years
    okay so for authorized_key2 only: (1) comment out the AuthorizedKeysFile (2) PasswordAuthentication no (3) PubkeyAuthentication yes (4) ChallengeResponseAuthentication no (5) test it ... if it still accepts passwords, also add UsePam no
  • YumYumYum
    YumYumYum almost 10 years
    Use this settings: fpaste.org/114544/04202660 when only allow SSH login via ~/.ssh/authorized_keys2 but not with username/password
  • Riccardo SCE
    Riccardo SCE almost 10 years
    and what's the DEFAULT value of it? I mean, what if I don't specify any "PasswordAuthentication" ?
  • Alexey
    Alexey almost 8 years
    I would appreciate some explanation of what UsePAM does...
  • Jan D
    Jan D about 7 years
    This answer is a little old, yet I'd like to add something: The great thing about Pubkey Authentication is that no secrets are transmitted to the server, at all. The private key remains secret on your computer, i.e. you can't accidentally transmit any kind of secret to a compromised or MITM server. So Pubkey is definitely favourable over Password auth. But anyway, yes, Password auth is way easier to implement.
  • Timo
    Timo over 6 years
    @TSERiccardo: Nobody answered your question? It's a shame, blame SO!
  • Riccardo SCE
    Riccardo SCE over 6 years
    Nope nobody did :P
  • admin
    admin over 5 years
    It wouldn't be a hassle setting it up, just on par to being lazy not to do it.
  • Starfish
    Starfish over 5 years
    @RiccardoSCE According to the sshd_config man page, the default for PasswordAuthentication is 'yes'.
  • pacoverflow
    pacoverflow over 3 years
    PubkeyAuthentication also defaults to yes.
  • Digger
    Digger over 3 years
    For my system (using ssh version OpenSSH_6.7p1 Debian-5+deb8u8, OpenSSL 1.0.1t 3 May 2016), the default condition was for said PasswordAuthentication line to be commented out and for the option to be set to yes