Como o Kerberos funciona com o SSH?

Question

Suponha que eu tenha quatro computadores, Laptop, Servidor1, Servidor2, servidor Kerberos:

• Efetuo login usando PuTTY ou SSH de L a S1, fornecendo meu nome de usuário / senha
• De S1 eu então SSH para S2. Nenhuma senha é necessária, pois o Kerberos me autentica

Descreva todas as trocas importantes do protocolo SSH e KRB5: "L envia o nome de usuário para S1", "K envia ... para S1", etc.

(Esta questão pretende ser editada pela comunidade; por favor melhore-a para o leitor não especialista .)

    

Answer 1

Primeiro login:

• L envia o nome de usuário e a solicitação de autenticação SSH para S1
• S1 retorna mecanismos de autenticação SSH disponíveis, com "senha" como um deles
• L escolhe "senha" e envia a senha simples para S1
• S1 fornece nome de usuário e senha para a pilha do PAM.
• No S1, o PAM (geralmente pam_krb5 ou pam_sss ) solicita um TGT (ticket de concessão de ticket) do Kerberos KDC.
  1. S1 obtém um TGT.
     • Estilo antigo (sem preauth): S1 envia um AS-REQ e recebe um AS-REP contendo o TGT.
     • Novo estilo (com preauth): S1 usa sua senha para criptografar o registro de data e hora atual e anexa-o ao AS-REQ. O servidor descriptografa o registro de data e hora e verifica se está dentro do tempo permitido. se a descriptografia falhar, a senha será imediatamente rejeitada. Caso contrário, um TGT é retornado no AS-REP.
  2. S1 tenta descriptografar o TGT usando uma chave gerada a partir de sua senha. Se a decodificação for bem-sucedida, a senha será aceita como correta.
  3. O TGT é armazenado em um cache de credenciais recém-criado. (Você pode inspecionar a variável de ambiente $KRB5CCNAME para localizar o ccache ou usar klist para listar seu conteúdo.)
• O S1 usa o PAM para executar verificações de autorização (dependentes da configuração) e abre a sessão.
  • Se pam_krb5 for chamado no estágio de autorização, ele verificará se ~/.k5login existe. Em caso afirmativo, ele deve listar o principal do Kerberos do cliente. Caso contrário, a única entidade principal permitida é username@DEFAULT-REALM .

Segundo login:

• S1 envia um nome de usuário e uma solicitação SSH automática para S2
• S2 retorna auth mechs disponíveis, sendo um deles "gssapi-with-mic" ¹
• O S1 solicita um tíquete para host/[e-mail] , enviando um TGS-REQ com o TGT para o KDC e recebendo um TGS-REP com o tíquete de serviço dele.
• S1 gera um "AP-REQ" (pedido de autenticação) e envia para S2.
• S2 tenta descriptografar o pedido. Se for bem sucedido, a autenticação é feita. (PAM não é usado para autenticação.)
  • Outros protocolos, como o LDAP, podem optar por criptografar outras transmissões de dados com uma "chave de sessão" incluída na solicitação; no entanto, o SSH já negociou sua própria camada de criptografia.
• Se a autenticação for bem-sucedida, o S2 usará o PAM para realizar verificações de autorização e abrir a sessão, o mesmo que o S1.
• Se o encaminhamento de credenciais estiver ativado e o TGT tiver o sinalizador "encaminhado", o S1 solicitará uma cópia do TGT do usuário (com o sinalizador "encaminhado" definido) e o enviará para o S2, onde será armazenado em um novo ccache . Isso permite logins recursivos autenticados pelo Kerberos.

Note que você também pode obter TGTs localmente. No Linux, você pode fazer isso usando kinit e, em seguida, conectar usando ssh -K . No Windows, se você estiver conectado a um domínio do Windows AD, o Windows fará isso por você; caso contrário, MIT Kerberos pode ser usado. O PuTTY 0.61 suporta o uso do Windows (SSPI) e do MIT (GSSAPI), embora você deva habilitar o encaminhamento (delegação) manualmente.

¹ gssapi-keyex também é possível, mas não foi aceito no OpenSSH oficial.

    

Answer 2

Para encurtar a história: de preferência, os tíquetes Kerberos devem ser obtidos no seu terminal (L), com o comando kinit ou como parte da sequência de login local em uma configuração chamada "conexão única" . Os sistemas remotos (S1, S2) seriam então acessíveis sem prompts de senha. Um acesso encadeado (L → S1 → S2) seria possível empregando uma técnica conhecida como "encaminhamento de tickets". Tal configuração requer, em particular, que o KDC seja diretamente acessível a partir do terminal (L).

A outra resposta de grawity explica essa abordagem em detalhes.

    

Answer 3

A única etapa não óbvia aqui é que há um módulo PAM no S1 que usou suas credenciais para executar um kinit e você recebe um ticket de concessão de ticket do K (autenticação do cliente). Então, quando você usa SSH para S2 usando a autenticação Kerberos, ocorre uma autenticação de serviço do cliente. Eu não vejo o benefício de passar por todas as tediosas trocas de mensagens por mensagem.

Lance um -vvv no seu comando ssh se quiser ver todas as mensagens e ler a descrição da Wikipedia de Kerberos.