Por que o sshd está engajando o PAM ainda?

3

Background / Behavior é: se você fizer um ssh para box via e o GSSAPI / Kerberos for bem-sucedido e você tiver um usuário local em / etc / passwd , você fará o login abaixo da configuração do PAM. Tudo bem lá.

Mas se você não tiver um usuário local em / etc / passwd , mas conseguir um tíquete de serviço host / XXXXXX (o GSSAPI funciona), o sshd falhará no login e nunca obterá prompts para o SecurID (nosso raio pam aponta para um SecurID). Eu entendi aquilo. Como o servidor 'autenticado' o usuário e o pam_unix sabem que o usuário não está em / etc / passwd, não há necessidade de engajar nenhum outro método de autenticação.

No entanto, a minha pergunta é por que é que se eu executo o kdestroy (intencionalmente tenho GSSAPI falha), (e ainda não existem no / etc / passwd) eu de repente recebo um prompt Securid (ou seja, PAM é engajado)?

Executando o sshd com os shows de depuração: adia o teclado interativo para o usuário inválido "user". Primeiro, por que simplesmente não falharia? Segundo por que demora? pam_radius é 'requisito', não 'obrigatório'.

Eu esperaria também simplesmente falhar porque, mesmo que eu não tenha autenticado, eu nunca passarei pelo pam_unix.

Arquivos:

/ etc / ssh / sshd_config

....  
ChallengeResponseAuthentication yes  
GSSAPIAuthentication            yes  
HostbasedAuthentication         no  
KerberosAuthentication          no  
PasswordAuthentication          no  
PubkeyAuthentication            yes  
RhostsRSAAuthentication         no  
RSAAuthentication               yes  
UsePAM                          yes      
....

/etc/pam.d/sshd

auth       requisite        pam_radius_auth.so conf=pam_radius_auth.conf debug retry=3  
auth       required     pam_nologin.so  
auth     required     pam_krb5.so.1  
account  sufficient      pam_radius_auth.so conf=pam_radius_auth.conf  
account    required     pam_stack.so service=system-auth  
password   required     pam_stack.so service=system-auth  
session    required     pam_stack.so service=system-auth  
session    required     pam_limits.so  
session    optional     pam_console.so  

/etc/pam.d/system-auth

auth        required      pam_env.so  
auth        sufficient    pam_krb5.so.1  
auth        sufficient    pam_unix.so  
auth        required      pam_deny.so  
account     required      pam_unix.so  
password    required      pam_cracklib.so retry=3  
password    sufficient    pam_unix.so use_authtok md5 shadow  
password    required      pam_deny.so  
session     required      pam_limits.so  
session     required      pam_unix.so  
    
por jouell 13.02.2015 / 06:18

1 resposta

3

A autenticação GSSAPI não é tratada pelo PAM. O módulo PAM para kerberos é usado para autenticação de senha de um usuário, usando o protocolo Kerberos para obter um ticket válido.

Existem 3 resultados da autenticação GSSAPI.

  1. Falha na autenticação porque as credenciais foram enviadas, mas as credenciais eram inválidas.
  2. A autenticação foi bem-sucedida usando as credenciais apresentadas.
  3. A autenticação é ignorada porque não foram fornecidas credenciais.

Se o resultado for 1, a solicitação será negada imediatamente, pois um token foi enviado, mas falhou. O SSHD não tenta outros métodos de autenticação.

Se o resultado for 3, sshd tentará em seguida outros métodos de autenticação, o que inclui a seção PAM auth .

Não estou familiarizado com pam_radius , mas suponho que ele solicite um token de autenticação, independentemente de o usuário existir ou não por motivos de segurança. A falha indica imediatamente a um usuário / atacante que tal usuário não existe, portanto, a partir de um processo de eliminação, você pode enumerar os usuários.

Quanto à opção "requisite", na configuração da pilha, "required" e "requisite" têm o mesmo efeito. pam_krb não pode solicitar um ticket sem um usuário válido, de modo que acabaria falhando imediatamente.

Para a configuração dada pam_unix não é usada para autenticação, mas autorização, esta é uma etapa que ocorre após a autenticação. Esclarecer; autenticação lida com provar que você é quem você diz que é, enquanto a autorização lida com você ter permissões corretas para fazer o que você quer fazer (que neste caso é o login).

    
por 13.02.2015 / 10:20