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).


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

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).

  • 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
  • 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

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;

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.