La autenticación SSH Kerberos falla con "Principal incorrecto en la solicitud / No tengo credenciales de cliente" en debian squeeze

8

Tengo un host de Debian Squeeze donde no puedo iniciar sesión con Kerberos sin una solicitud de contraseña. Un host ubuntu 12.04 configurado de manera idéntica funciona bien y puede iniciar sesión sin obtener una solicitud de contraseña.

Después de un kinit, klist da:

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

Ahora, cuando intento iniciar sesión a través de ssh en debian-squeeze, aparece el mensaje de contraseña. Si reviso mis boletos en este punto sin hacer una autenticación, obtengo:

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

Entonces, obviamente, me otorgan un boleto. Sin embargo, el registro de depuración ssh proporciona:

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

Esto es bastante similar a lo que se describe aquí , aquí y en este informe de errores .

Mi DNS está bien. Ya intenté recrear los principales / claves. Así que ninguna de las soluciones ayudó que se publicaron allí.

¿Alguna pista?

— b0ti
fuente

Solo para cubrir lo básico, ¿ha verificado si los relojes de todas las máquinas están sincronizados?

— chutz

Todos estos son contenedores lxc que se ejecutan en el mismo host físico. Los relojes no podrían estar más sincronizados que esto.

— b0ti

7

En el resultado de muestra, veo que tienes una clave para a debian-squeeze: un nombre de host sin puntos. Esto demuestra que configuró su resolución inversa para señalar el nombre corto. ¿Es realmente un nombre que no es FQDN lo que ves, o fue editado para la pregunta?

Kerberos debería funcionar con cualquiera de los dos, pero puede verificar que el host mismo piense que se llama debian-squeeze. Compruebe que la búsqueda directa -> inversa en el interior debian-squeezerealmente resuelve debian-squeeze:

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

Realmente no he oído hablar de que Kerberos se implemente con nombres cortos, por lo que si tiene una opción, puede ser una buena idea quedarse con los FQDN.

Actualizar:

El cliente actualmente está obteniendo una clave para el nombre corto, pero el servidor cree que está correctamente nombrado con un nombre largo. Lo más probable es que el problema esté ahí. Solo para estar seguro, intente lo siguiente:

Verifique la búsqueda directa / inversa del nombre del cliente. Es decir
```
$ getent hosts debian-squeeze | awk '{print $1; exit}' | xargs getent hosts | awk '{print $2}'
```
El nombre devuelto es aquel para el que el cliente intentará obtener un ticket. A juzgar por su salida, este es probablemente el nombre corto.

Verifique qué claves están presentes en el 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
...

En la lista, debería ver un principal que coincida con el nombre de host del comando anterior. Si no está allí, entonces ese es tu problema. Si está ahí ...

Verifique que la versión clave en el servidor kerberos sea la misma que la del debian-squeeze. En el cliente, obtenga una clave explícitamente y verifique la versión "KVNO" al final de la línea:
```
$ kvno host/debian-squeeze.realm
host/debian-squeeze.realm@REALM: kvno = 1
```

En cualquier caso, el nombre de host y la versión "kvno" en todos estos comandos deben coincidir.

— chutz
fuente

El host se llama 'debian-squeeze' tal como lo devuelve hostname. La IP se asigna de nuevo al FQDN, por lo que el comando que le dio devuelve 'debian-squeeze.realm'. Como nota al margen: tengo dos claves configuradas para este host, una para el fqdn y otra para el nombre corto. ¿Podría ser esto un desastre?

— b0ti

Muy bien, actualicé mi respuesta con más cosas que debes verificar. Es muy probable que sea un nombre corto / FQDN confusión.

— chutz

¡Muchas gracias! De hecho, mi problema fue causado por la clave adicional con el nombre de host corto. Solo desearía que fuera más fácil depurar tales problemas para que los registros indiquen cuál es el principal problemático.

— b0ti

0

He visto este error cuando / etc / hosts en el servidor incluye una entrada para su dirección IP que no coincide con lo que está en DNS o la tabla de claves. ¿Ha verificado (o eliminado) todas las entradas de host no locales de / etc / hosts?

— slushpupie
fuente

El DNS está bien. Solo entradas localhost en / etc / hosts.

— b0ti