Autenticação de dois fatores OpenSSH combinada com Kerberos / chave pública

4

Estou tentando implementar a autenticação de dois fatores para o OpenSSH. O ambiente é Centos 7 (kernel: 3.10.0-229.1.2.el7.x86_64) com OpenSSH_6.6.1p1, OpenSSL 1.0.1e-fips 11 de fevereiro de 2013. Temos o Active Directory (LDAP) + Kerberos implantado. A especificação é a seguinte:

  • Um usuário com um ticket Kerberos válido e existente deve ser solicitado apenas para o segundo fator
  • Um usuário sem um ticket Kerberos válido e válido deve ser solicitado para a senha e um segundo fator
  • Usuários locais (sem acesso LDAP) devem ser capazes de autenticar com suas senhas locais
  • O segundo fator não deve ser oferecido antes do primeiro
  • Além do Kerberos, a autenticação de chave pública também deve ser aceita como primeiro fator, se disponível
  • O recurso deve poder ser limitado a um conjunto de usuários - outros apenas podem entrar com suas senhas

Para realizar o processo de autenticação do segundo fator, existe um módulo PAM de terceiros disponível que não sabe nada sobre o Kerberos. Então, aqui está o que eu fiz:

Coloque estas linhas em / etc / ssh / sshd_config:

# To enable PAM - this will make sshd use PAM with configuration /etc/pam.d/sshd
UsePam yes
ChallengeResponseAuthentication yes

# To enable Kerberos and public key authentication - it will let sshd use existing Kerberos tickets
GSSAPIAuthentication yes

# Enable public key authentication
PubkeyAuthentication yes

# Password validation should be done via the KDC
PasswordAuthentication yes
KerberosAuthentication yes
KerberosOrLocalPasswd yes

# Kerberos / Public Key + PAM
AuthenticationMethods gssapi-with-mic,keyboard-interactive:pam publickey,keyboard-interactive:pam password,keyboard-interactive:pam
# (only supported for OpenSSH 6.2 or higher)

A seção auth da configuração do PAM para sshd (/etc/pam.d/sshd)

auth       [success=ignore default=1] pam_localuser.so
auth       substack     password-auth
auth       [success=1 default=ignore] pam_localuser.so
auth       required     pam_2fa.so [...some arguments...]
auth       include      postlogin

O módulo pam_2fa.so é responsável por solicitar e validar o segundo fator.

Agora, para o Kerberos, isso faz quase tudo que eu queria alcançar. No entanto, para contas locais, isso resulta em dois prompts de senha subsequentes. Este é o meu principal problema aqui. Isso ocorre porque, nesse caso, o caminho "password, keyboard-interactive: pam" é usado, como esperado. (Preciso desse caminho de autenticação para que alguém com uma conta Kerberos, mas sem um ticket válido, possa obter um ticket digitando a senha e depois a OTP.) Se eu remover completamente a subchagem password-auth da configuração do PAM, as contas do Kerberos continuarão funcionando e contas locais permanecem não funcionando. Para mim, parece que a instrução yes KerberosOrLocalPasswd é ignorada, porque UsePAM yes também está presente. No entanto, o sshd realmente continua usando o KDC para validação de senha, porque senão não funcionaria para contas LDAP.

Então, novamente, para esclarecer melhor o que eu quero implementar aqui é o pseudocódigo que descreveu a lógica de autenticação desejada:

if gssapi_auth_ok(principal) or pubkey_auth_ok(pubkey):
  return second_factor_auth(user, read_otp())
else:
  if is_local_account(user):
    if local_passwd_auth(user, read_password()):
      return second_factor_auth(user, read_otp())
    else:
      return AUTH_ERR
  else:
    if krb5_auth(principal, read_password()):
      return second_factor_auth(user, read_otp())
    return AUTH_ERR

Então, meu cenário não é muito complexo ou ambicioso, mas ainda não consegui encontrar uma maneira clara de implementá-lo, apesar de ter passado dias pesquisando e experimentando. Você poderia, por favor, me ajudar a encontrar uma solução?

Muito obrigado antecipadamente!

    
por dgyuri92 04.05.2015 / 17:02

2 respostas

1

Eu não sei de nenhuma maneira de fazer o que você quer com o PAM sem escrever um novo módulo pam. O PAM é relativamente complexo e a maneira que o sshd interage com o PAM e o kerberos tem sido na minha experiência tal que sempre há um caso de borda que simplesmente não funciona.

O que você quer pode ser possível, eu simplesmente não sei como fazer isso. Se você precisa apenas proteger o ssh, o que eu sugiro é usar

ForceCommand  /path/to/2fa_executable 

no seu sshd_config. Isto permitiria que você implementasse a lógica que você quer, a desvantagem é que o 2fa_executable precisa ser setuid para ler quaisquer segredos do 2fa.

Há um exemplo e um código no site de segurança do Duo. Você pode usar o wrapper duu setuid e qualquer código 2fa que você esteja usando.

Configuração do Duo Unix

    
por 06.05.2015 / 20:57
1
  • A user with an existing, valid Kerberos ticket must be asked only for the second factor.

Isso não pode ser alcançado por meio do PAM.

A autenticação bem-sucedida baseada em chave executada no sshd ignora a pilha auth do PAM. Isso inclui o GSSAPI, que é um requisito para autenticação Kerberos baseada em ticket. Não tem escolha a não ser fazer isso, pois o PAM simplesmente não foi projetado com esse tipo de autenticação em mente.

A configuração de UsePAM yes faz o seguinte:

  • ChallengeResponseAuthentication e PasswordAuthentication engancharão a pilha auth do PAM para validar a senha. Qualquer forma de autenticação diferente desses dois métodos não tocará na pilha auth .
  • Na autenticação bem-sucedida, a pilha account do PAM será chamada para determinar se o usuário autenticado tem permissão de acesso. (sempre)
  • A pilha session do PAM será chamada para manipular as tarefas de configuração da sessão.

Resumo: Não há absolutamente nenhuma maneira de fazer com que um prompt de autenticação de dois fatores localizado dentro da pilha auth seja acionado por alguém que tenha sido autenticado com uma chave GSSAPI ou ssh. Você pode usar account e session stacks em conjunto com esses métodos de autenticação, mas isso é tão longe quanto o PAM.

    
por 07.05.2015 / 02:13