A autenticação Kerberos SSH falha com “Principal errado na solicitação / Não obteve credenciais de cliente” no debian squeeze

Question

Eu tenho um host squeeze debian onde não consigo logar com o kerberos sem um prompt de senha. Um host ubuntu 12.04 configurado de forma idêntica funciona bem e pode efetuar login sem obter um prompt de senha.

Depois de um kinit, o klist dá:

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: boti@REALM

Valid starting    Expires           Service principal
14/02/2013 16:37  15/02/2013 16:37  krbtgt/REALM@REALM

Agora, quando tento efetuar login no ssh no debian-squeeze, recebo a solicitação de senha. Se eu verificar meus tickets neste momento sem fazer uma autenticação, recebo:

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: boti@REALM

Valid starting    Expires           Service principal
14/02/2013 16:37  15/02/2013 16:37  krbtgt/REALM@REALM
14/02/2013 16:38  15/02/2013 16:37  host/debian-squeeze@
14/02/2013 16:38  15/02/2013 16:37  host/debian-squeeze@REALM

Então, obviamente, eu recebo um bilhete. No entanto, o log de depuração do ssh fornece:

Postponed gssapi-with-mic for boti from 192.168.255.98 port 59557 ssh2
debug3: mm_request_send entering: type 40
debug3: mm_request_receive_expect entering: type 41
debug3: mm_request_receive entering
debug3: monitor_read: checking request 40
debug1: Unspecified GSS failure.  Minor code may provide more information
Wrong principal in request

Isso é bem parecido com o que é descrito aqui , aqui e em este relatório de erros .

Meu DNS está bem. Já tentei recriar os principais / chaves. Então, nenhuma das soluções ajudou que foram postadas lá.

Alguma dica?

    

Answer 1

Na saída de amostra, vejo que você tem uma chave para um debian-squeeze - um nome de host sem pontos nele. Isso prova que você configurou sua resolução inversa para apontar para o nome abreviado. Esse é realmente um nome não-FQDN que você vê ou foi editado para a pergunta?

O Kerberos deve funcionar com qualquer um deles, mas você pode verificar novamente se o host em si acha que ele é chamado de debian-squeeze . Verifique se o encaminhamento - > A pesquisa inversa dentro de debian-squeeze realmente resolve para debian-squeeze :

$ getent hosts $(hostname) | awk '{print $1; exit}' | xargs getent hosts | awk '{print $2}'

Eu realmente não ouvi falar do Kerberos sendo implantado com nomes curtos, então se você tiver uma escolha, pode ser uma boa idéia ficar com os FQDNs.

Atualização:

O cliente está recebendo atualmente uma chave para o nome abreviado, mas o servidor acha que ele está corretamente nomeado com um nome longo. Muito provavelmente, o problema está lá. Só para ter certeza, tente o seguinte:

1. Verifique a pesquisa de nome de encaminhamento / retorno do cliente. Ou seja,

   $ getent hosts debian-squeeze | awk '{print $1; exit}' | xargs getent hosts | awk '{print $2}'
   

   O nome retornado é aquele para o qual o cliente tentará obter um ticket. A julgar pela sua saída, este é provavelmente o nome curto.

2. Verifique quais chaves estão presentes no servidor.

   $ sudo klist -k /etc/krb5.keytab
   Keytab name: WRFILE:/etc/krb5.keytab
   KVNO Principal
   ---- --------------------------------------------------------------------------
      1 host/debian-squeeze.realm@REALM
      1 host/debian-squeeze.realm@REALM
      1 host/debian-squeeze.realm@REALM
      1 host/debian-squeeze.realm@REALM
   ...
   

   Na lista, você deve ver um principal correspondente ao nome do host do comando anterior. Se não está lá, então esse é o seu problema. Se está aí ...

3. Verifique se a versão da chave no servidor kerberos é a mesma que a do debian-squeeze . No cliente, obtenha uma chave explicitamente e verifique a versão "KVNO" no final da linha:

   $ kvno host/debian-squeeze.realm
   host/debian-squeeze.realm@REALM: kvno = 1
   

De qualquer forma, o nome do host e a versão "kvno" em todos esses comandos devem corresponder.

    

Answer 2

Só para cobrir o básico, você verificou se os relógios de todas as máquinas estão sincronizados?

    

Answer 3

Eu vi esse erro quando / etc / hosts no servidor inclui uma entrada para seu endereço IP que não corresponde ao que está no DNS ou no keytab. Você verificou novamente (ou removeu) todas as entradas não locais de / etc / hosts?