Best way to restrict some SSH users to publickey authentication only (disable password authentication)

Question

I'm running Mac OS X Server.app on Yosemite and I have SSH enabled for users with the default settings in /etc/sshd_config (publickey and password auth enabled by default). However, I need to restrict the git local user to have publickey access ONLY via SSH.

Full disclosure, the Server.app enables some additional Kerberos and GSSAPI options (although I'm not 100% sure how these effect my questions below):

# Kerberos options
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIStrictAcceptorCheck yes
GSSAPIKeyExchange no

/etc/sshd_config says the following:

# To disable tunneled clear text passwords both PasswordAuthentication and
# ChallengeResponseAuthentication must be set to "no".

However, ChallengeResponseAuthentication is not allowed in match statements, so I tried just disabling password authentication only:

Match User git
      PasswordAuthentication no

This does not work--I was still able to log in with username/password to git@my.server :(

However, adding KbdInteractiveAuthentication no seemed to work correctly:

Match User git
      PasswordAuthentication no
      KbdInteractiveAuthentication no

Now I get Permission denied (publickey,gssapi-keyex,gssapi-with-mic) when trying to log in without a public key. This seems to indicate that there are still methods besides publickey which will allow login from the git user (i.e. gssapi-keyex and gssapi-with-mic)

It seems like a better approach is to simply restrict the authentication method to publickey:

Match User git
    AuthenticationMethods publickey

This gives the response `Permission denied (publickey).

Questions:

What's the difference between ChallengeResponseAuthentication and KbdInteractiveAuthentication? Why is KbdInteractiveAuthentication allowed in match statements but not ChallengeResponseAuthentication?
Is there any downside/security concern with the AuthenticationMethods publickey approach?
(Bonus if you can help me understand gssapi-keyex/gssapi-with-mic and how they relate to the GSSAPI/Kerberos options that were enabled)

Paul Haldane · Accepted Answer · 2017-05-18T10:46:11.337

6

There's a nice summary of the difference between ChallengeResponseAuthentication and KbdInteractiveAuthentication at http://blog.tankywoo.com/linux/2013/09/14/ssh-passwordauthentication-vs-challengeresponseauthentication.html - summary is that ChallengeResponse often ends up just asking for password (but insists on it being supplied interactively).

KbdInteractiveAuthentication and ChallengeResponseAuthentication are different things. It's just that ChallengeResponseAuthentication can end up just prompting for a password in simple cases.

ChallengeResponseAuthentication is a global setting and can't be specified within a Match clause - see the sshd_config man page for details.

Explicitly specifying AuthenticationMethods publickey for the git user should work fine and is better than than disabling the ones you don't want (as the list could change).

The gssapi options come into play if you're working in a Kerberos environment (such as an Active Directory domain).

edited May 18 '17 at 10:46

answered Apr 15 '15 at 20:35

Paul Haldane

4,457
1
20
31

Thanks for the helpful link. Any idea about the 2nd part of question #1 above? Why is `KbdInteractiveAuthentication` allowed in match statements but not `ChallengeResponseAuthentication`? Are these actually different things, or does the name just change inside a match block? – cdwilson Apr 16 '15 at 21:49
1

See update to answer (along with `sshd_config` man page for details) – Paul Haldane Apr 17 '15 at 11:29
1

I've awarded the bounty because I appreciate the response, but the man page and the other links you provided still don't give a good description of the differences between `KbdInteractiveAuthentication` and `ChallengeResponseAuthentication` (and why match only accepts `KbdInteractiveAuthentication`). If you (or someone else) can edit this answer to provide more details, I would appreciate it. – cdwilson Apr 22 '15 at 21:31
The link in question doesn't address the keyword `KbdInteractiveAuthentication` at all. – Dan Pritts Nov 14 '18 at 19:55
From the [sshd_config](https://man7.org/linux/man-pages/man5/sshd_config.5.html) manpage, `ChallengeResponseAuthentication` is a deprecated alias for `KbdInteractiveAuthentication `. – cbracken May 21 '22 at 06:31

score 1 · Answer 2 · answered Nov 14 '18 at 19:52

It's not entirely clear to me if there is any difference, but at the very least, ChallengeResponseAuthentication seems to require KbdInteractiveAuthentication; it is automatically turned on if Challenge-Response is enabled.

I get the feeling from reading it that they came up with Challenge-Response during the SSH1 era. It was standardized as keyboard-interactive with SSH2, but they didn't immediately change the server config file, to enable old configs to continue to work.

I found the following in the openssh-portable source (as of 20181214).

sshd.c starting at line 1685:

 /* challenge-response is implemented via keyboard interactive */
 if (options.challenge_response_authentication)
    options.kbd_interactive_authentication = 1;

sshconnect2.c starting at line 375:

 if (options.challenge_response_authentication)
    options.kbd_interactive_authentication = 1;

Best way to restrict some SSH users to publickey authentication only (disable password authentication)

2 Answers2