Como o Kerberos trabalha com SSH?

Suponha que eu tenha quatro computadores, laptop, servidor1, servidor2, servidor Kerberos:

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

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

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

Primeiro login:

• L envia nome de usuário e 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 à pilha do PAM.
• No S1, o PAM (geralmente pam_krb5ou pam_sss) solicita um TGT (ticket de concessão de ticket) ao KDC do Kerberos.
  1. S1 obtém um TGT.
     • Estilo antigo (sem pré-filtro): S1 envia um AS-REQ e recebe um AS-REP contendo o TGT.
     • Novo estilo (com pré-filtro): o S1 usa sua senha para criptografar o carimbo de data / hora atual e o anexa ao AS-REQ. O servidor descriptografa o carimbo 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. O S1 tenta descriptografar o TGT usando uma chave gerada a partir da sua senha. Se a descriptografia 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 $KRB5CCNAMEvariável de ambiente para encontrar o ccache ou usar klistpara listar seu conteúdo.)
• O S1 usa o PAM para executar verificações de autorização (dependentes da configuração) e abrir a sessão.
  • Se pam_krb5for chamado no estágio de autorização, ele verifica se ~/.k5loginexiste. Caso isso aconteça, ele deve listar o principal do Kerberos do cliente. Caso contrário, o único principal permitido é .username@DEFAULT-REALM

Segundo login:

• S1 envia nome de usuário e solicitação de autenticação automática de SSH para S2
• S2 retorna mecanismos de autenticação disponíveis, sendo um deles "gssapi-with-mic" ¹
• O S1 solicita um ticket , enviando um TGS-REQ com o TGT para o KDC e recebendo um TGS-REP com o ticket de serviço.host/s2.example.com@EXAMPLE.COM
• S1 gera um "AP-REQ" (solicitação de autenticação) e envia para S2.
• S2 tenta descriptografar a solicitação. Se for bem-sucedido, a autenticação é feita. (O PAM não é usado para autenticação.)
  • Outros protocolos, como o LDAP, podem optar por criptografar mais a transmissão 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 executar verificações de autorização e abrir a sessão, o mesmo que S1.
• Se o encaminhamento de credenciais foi ativado e o TGT possui o sinalizador "encaminhado", o S1 solicita uma cópia do TGT do usuário (com o sinalizador "encaminhado" definido) e o envia para o S2, onde é armazenado em um novo ccache. Isso permite logins autenticados por Kerberos recursivos.

Observe que você também pode obter TGTs localmente. No Linux, você pode fazer isso usando kinite 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, o MIT Kerberos pode ser usado. O PuTTY 0.61 suporta o uso do Windows (SSPI) e do MIT (GSSAPI), embora seja necessário ativar o encaminhamento (delegação) manualmente.

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

Para resumir a história: idealmente, os tíquetes Kerberos devem ser obtidos no seu terminal (L), com kinitcomando ou como parte da sequência de logon local em uma configuração chamada de "logon único". Os sistemas remotos (S1, S2) ficariam acessíveis sem avisos de senha. Um acesso encadeado (L → S1 → S2) seria possível empregando uma técnica conhecida como "encaminhamento de ticket". Essa configuração requer, em particular, que o KDC seja diretamente acessível a partir do terminal (L).

A outra resposta do grawity explica essa abordagem em detalhes.

A única etapa não óbvia aqui seria a existência de um módulo PAM no S1 que usava suas credenciais para executar kinitae obtém um ticket concedendo ticket a partir do K (autenticação de cliente). Em seguida, quando você SSH para S2 usando a autenticação Kerberos, ocorre uma autenticação de serviço ao cliente. Não vejo o benefício de passar por todas as trocas tediosas mensagem por mensagem.

Jogue um -vvvno seu comando ssh se você quiser ver todas as mensagens e leia a descrição da Wikipedia do Kerberos.