A melhor maneira de restringir alguns usuários SSH à autenticação de chave pública (desabilitar a autenticação por senha)

Question

Estou executando o Mac OS X Server.app no Yosemite e tenho o SSH ativado para usuários com as configurações padrão em /etc/sshd_config (chave pública e senha ativadas por padrão). No entanto, preciso restringir o usuário local git a ter acesso publickey APENAS via SSH.

Divulgação completa, o Server.app ativa algumas opções adicionais de Kerberos e GSSAPI (embora eu não tenha 100% de certeza de como isso afeta minhas perguntas abaixo):

# Kerberos options
KerberosAuthentication yes
KerberosOrLocalPasswd yes
KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
GSSAPIStrictAcceptorCheck yes
GSSAPIKeyExchange no

/etc/sshd_config diz o seguinte:

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

No entanto, ChallengeResponseAuthentication não é permitido em declarações de correspondência, por isso tentei apenas desativar a autenticação de senha apenas:

Match User git
      PasswordAuthentication no

Isso não funciona - ainda consegui fazer o login com nome de usuário / senha para [email protected]: (

No entanto, adicionar KbdInteractiveAuthentication no parece funcionar corretamente:

Match User git
      PasswordAuthentication no
      KbdInteractiveAuthentication no

Agora obtenho Permission denied (publickey,gssapi-keyex,gssapi-with-mic) ao tentar efetuar login sem uma chave pública. Isso parece indicar que ainda existem métodos além de publickey que permitirão o login do usuário git (por exemplo, gssapi-keyex e gssapi-with-mic )

Parece que uma abordagem melhor é simplesmente restringir o método de autenticação para publickey :

Match User git
    AuthenticationMethods publickey

Isso dá a resposta 'Permissão negada (publickey).

Perguntas:

1. Qual é a diferença entre ChallengeResponseAuthentication e %código%? Porque é KbdInteractiveAuthentication permitido nas declarações de correspondência, mas não KbdInteractiveAuthentication ?
2. Existe algum problema de segurança / desvantagem com a abordagem ChallengeResponseAuthentication ?
3. (Bônus se você puder me ajudar a entender AuthenticationMethods publickey / gssapi-keyex e como eles se relacionam com as opções GSSAPI / Kerberos que foram ativadas)

Answer 1

Há um bom resumo da diferença entre ChallengeResponseAuthentication e KbdInteractiveAuthentication em link - o resumo é que a ChallengeResponse geralmente acaba pedindo senha (mas insiste em que seja fornecido de forma interativa).

KbdInteractiveAuthentication e ChallengeResponseAuthentication são coisas diferentes. É só que ChallengeResponseAuthentication pode acabar apenas solicitando uma senha em casos simples.

ChallengeResponseAuthentication é uma configuração global e não pode ser especificada em uma cláusula Match - consulte a página sshd_config man para obter detalhes.

Especificar explicitamente AuthenticationMethods publickey para o usuário git deve funcionar bem e é melhor do que desativar os que você não quer (pois a lista pode mudar).

As opções gssapi entram em ação se você estiver trabalhando em um ambiente Kerberos (como um domínio do Active Directory).

    

Answer 2

Não está totalmente claro para mim se existe alguma diferença, mas no mínimo, ChallengeResponseAuthentication parece requerer KbdInteractiveAuthentication; Ele é ativado automaticamente se a resposta de desafio estiver ativada.

Eu tenho a sensação de ler que eles vieram com desafio-resposta durante a era SSH1. Ele foi padronizado como interativo com teclado com SSH2, mas eles não alteraram imediatamente o arquivo de configuração do servidor, para permitir que as configurações antigas continuassem a funcionar.

Encontrei o seguinte na fonte openssh-portable (a partir de 20181214).

sshd.c a partir da linha 1685:

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

sshconnect2.c a partir da linha 375:

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