La configuración de huellas dactilares ssh en dns para reemplazar conocido_hosts falla

Los registros SSHFP se generaron en el servidor ssh de la siguiente manera y luego se agregaron a la zona en enlace:

$ ssh-keygen -r www.test.us.
www.test.us. IN SSHFP 1 1 ad04dfaf343a93beeb939eed1612168f7eadbed7
www.test.us. IN SSHFP 2 1 432209c72c4f0e99546d601dd96c04ce804191f9

Los registros requeridos se pueden obtener del cliente ssh a través de DNS como se muestra:

$ dig www.test.us any
;; QUESTION SECTION:
;www.test.us.           IN  ANY

;; ANSWER SECTION:
www.test.us.        120 IN  SSHFP   1 1 AD04DFAF343A93BEEB939EED1612168F7EADBED7
www.test.us.        120 IN  SSHFP   2 1 432209C72C4F0E99546D601DD96C04CE804191F9
www.test.us.        120 IN  A   192.168.1.50

Sin embargo, ssh en el cliente no puede encontrarlos cuando se conecta:

$ rm .ssh/known_hosts
$ ssh -vo VerifyHostKeyDNS=yes www
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /Users/test/.ssh/config
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to www [192.168.1.50] port 22.
debug1: Connection established.
debug1: identity file /Users/test/.ssh/id_rsa type 1
debug1: identity file /Users/test/.ssh/id_rsa-cert type -1
debug1: identity file /Users/test/.ssh/id_dsa type -1
debug1: identity file /Users/test/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.8p2_hpn13v11
debug1: match: OpenSSH_5.8p2_hpn13v11 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 69:dc:47:97:e1:a5:c9:07:4a:2b:9e:3c:a2:2b:c8:8c
DNS lookup error: name does not exist
The authenticity of host 'www (192.168.1.50)' can't be established.
RSA key fingerprint is 69:dc:47:97:e1:a5:c9:07:4a:2b:9e:3c:a2:2b:c8:8c.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

¿Alguna idea de por qué esto está fallando? Sé que se requiere DNSSEC para hacerlo seguro y que debería recibir una advertencia ya que DNSSEC no está habilitado actualmente. Espero que esto funcione sin DNSSEC antes de comenzar a abordarlo como un problema adicional.

El servidor ssh es FreeBSD 9.1 con OpenSSH_5.8p2_hpn13v11 y también aloja DNS utilizando BIND 9.8.3-P4. Intenté conectarme desde OS X 10.8.2 con OpenSSH_5.9p1 y Arch Linux 3.6.10-1-ARCH con OpenSSH_6.1p1.

Actualizar

En un intento adicional de solucionar este problema, puse de pie una nueva máquina virtual OpenBSD 5.2 que tiene OpenSSH_6.1 incorporado como un servidor ssh. Dado que todas las demás implementaciones del servidor OpenSSH son solo puertos del OpenBSD, seguramente esto debería funcionar. En el servidor genero los registros SSHFP:

# ssh-keygen -r vm1.test.us.  
vm1.test.us. IN SSHFP 1 1 419c5338920e11183380d81f002fc998389b944f
vm1.test.us. IN SSHFP 1 2 cb5bbbf5aef231f57a1a4dcf1e790f1be032b124d0d591023f33cfd5f91ec556
vm1.test.us. IN SSHFP 2 1 0fdf92ce946b5cfee5f96a3e1ef710edc50280ff
vm1.test.us. IN SSHFP 2 2 f2ee7334ee9f9a426f51f20af8f4bc7155d567c9d38a6bffaa6c643af405711e
vm1.test.us. IN SSHFP 3 1 b5e94320f0bc0b46cc6627ca7221679a65c79962
vm1.test.us. IN SSHFP 3 2 60704213a0bbd8dae813d113bfe4ae190a780b89836e6e1c567b7cfde89805f8

Los agrego al servidor de enlace de FreeBSD y vuelvo a cargar named. Luego pruebe para ver si puedo acceder a los registros:

$ host -t any vm1
vm1.test.us has SSHFP record 1 1 419C5338920E11183380D81F002FC998389B944F
vm1.test.us has SSHFP record 1 2 CB5BBBF5AEF231F57A1A4DCF1E790F1BE032B124D0D591023F33CFD5 F91EC556
vm1.test.us has SSHFP record 2 1 0FDF92CE946B5CFEE5F96A3E1EF710EDC50280FF
vm1.test.us has SSHFP record 2 2 F2EE7334EE9F9A426F51F20AF8F4BC7155D567C9D38A6BFFAA6C643A F405711E
vm1.test.us has SSHFP record 3 1 B5E94320F0BC0B46CC6627CA7221679A65C79962
vm1.test.us has SSHFP record 3 2 60704213A0BBD8DAE813D113BFE4AE190A780B89836E6E1C567B7CFD E89805F8
vm1.test.us has address 192.168.1.60


$ dig -t any vm1.test.us
;; QUESTION SECTION:
;vm1.test.us.           IN  ANY

;; ANSWER SECTION:
vm1.test.us.        120 IN  SSHFP   1 2 CB5BBBF5AEF231F57A1A4DCF1E790F1BE032B124D0D591023F33CFD5 F91EC556
vm1.test.us.        120 IN  SSHFP   2 1 0FDF92CE946B5CFEE5F96A3E1EF710EDC50280FF
vm1.test.us.        120 IN  SSHFP   2 2 F2EE7334EE9F9A426F51F20AF8F4BC7155D567C9D38A6BFFAA6C643A F405711E
vm1.test.us.        120 IN  SSHFP   3 1 B5E94320F0BC0B46CC6627CA7221679A65C79962
vm1.test.us.        120 IN  SSHFP   3 2 60704213A0BBD8DAE813D113BFE4AE190A780B89836E6E1C567B7CFD E89805F8
vm1.test.us.        120 IN  SSHFP   1 1 419C5338920E11183380D81F002FC998389B944F
vm1.test.us.        120 IN  A   192.168.1.60

Los registros claramente se están sirviendo a través de DNS, así que trato de usar ssh:

$ rm .ssh/known_hosts
$ ssh -vo VerifyHostKeyDNS=yes root@vm1
OpenSSH_5.9p1, OpenSSL 0.9.8r 8 Feb 2011
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to vm1 [192.168.1.60] port 22.
debug1: Connection established.
debug1: identity file /Users/test/.ssh/id_rsa type 1
debug1: identity file /Users/test/.ssh/id_rsa-cert type -1
debug1: identity file /Users/test/.ssh/id_dsa type -1
debug1: identity file /Users/test/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.1
debug1: match: OpenSSH_6.1 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.9
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA d8:01:b5:b2:3e:c7:55:ce:19:c1:6d:77:39:92:7d:0f
DNS lookup error: name does not exist
The authenticity of host 'vm1 (192.168.1.60)' can't be established.
RSA key fingerprint is d8:01:b5:b2:3e:c7:55:ce:19:c1:6d:77:39:92:7d:0f.
No matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)? 

En este punto, creo que es seguro eliminar los clientes y servidores ssh como punto de falla. En cambio, voy a enfocar el servidor DNS. A menos que alguien tenga una sugerencia de dónde buscar, creo que estoy atrapado en tomar capturas de paquetes y buscar en ellas para encontrar pistas.

Actualización2

Bien, aquí están los resultados de mis capturas de paquetes. ssh www; falla con el estándar

No matching host key fingerprint found in DNS.

y la captura de paquetes muestra que DNS no puede devolver un registro para la búsqueda.

mbp13.test.us   www.test.us DNS Standard query 0x1c5e  SSHFP www
www.test.us   mbp13.test.us DNS Standard query response 0x1c5e No such name

Comparar con ssh www.test.us; que también falla con el mensaje

No matching host key fingerprint found in DNS.

sin embargo, la captura de paquetes muestra que DNS realmente devuelve el registro.

mbp13.test.us   www.test.us DNS Standard query 0x0ebd  SSHFP www.test.us
www.test.us   mbp13.test.us DNS Standard query response 0x0ebd  SSHFP SSHFP`

Primero, es un poco desconcertante que el mensaje de error sea el mismo para ambos casos. Puedo agregar algunos registros para arreglar el caso 1 donde no se devuelven registros, pero el gran problema es el caso 2. DNS funciona y los registros SSHFP se devuelven al cliente ssh. No se envían paquetes después de la respuesta de consulta DNS y el cliente ssh muestra inmediatamente el mensaje de huella digital no coincidente. Esto significa que todos los clientes ssh con los que estoy probando están rotos o la huella digital almacenada en DNS es incorrecta y no coincide. Dudo que sean los clientes, ¿por qué la huella digital en DNS es incorrecta? Las huellas digitales se generaron a partir de las herramientas ssh integradas ssh-keygen como se describe al comienzo de esta publicación. Además, el problema no se ve ayudado por el hecho de que las huellas digitales se muestran en diferentes formatos según el contexto.

DNS record format:      ad04dfaf343a93beeb939eed1612168f7eadbed7
ssh client mesg format: 69:dc:47:97:e1:a5:c9:07:4a:2b:9e:3c:a2:2b:c8:8c

¿Alguien tiene alguna sugerencia de por qué las huellas dactilares de ssh-keygen -r no coinciden con las claves públicas devueltas por el mismo servidor ssh?

Actualización3

Estoy en mi última opción. A menos que alguien me señale en la dirección correcta antes del fin de semana, pasaré mi sábado creando un entorno duplicado usando máquinas virtuales que esté completamente basado en OpenBSD. Dado que OpenBSD posee OpenSSH, estas deberían ser condiciones ideales para que SSHFP sobre DNS funcione. Si un servidor OpenBSD OpenSSH con enlace que sirve a un cliente OpenBSD OpenSSH no funciona, entonces SSHFP se rompe según lo implementado y moveré las cosas a los foros de OpenBSD y posiblemente presentaré un informe de error. Todavía espero perder algo obvio y que una respuesta útil me salve el fin de semana.

Aparentemente mis problemas fueron causados ​​por dos problemas diferentes.

Problema n. ° 1 SSHFP no admite el uso de rutas de búsqueda. Entonces, si agrega "dominio example.com" a /etc/resolv.conf, entonces esperaría que ssh myhost funcione con SSHFP ya que ssh regular resolverá correctamente el nombre de myhost.example.com. Aparentemente, los desarrolladores de OpenBSD son conscientes del problema ya que se emitió un parche hace 2 años, pero nunca se aplicó. En cambio, se sugirió un truco ssh_config pero tampoco parece funcionar. Entonces, la solución al primer problema es que el FQDN siempre debe usarse con SSHFP.

Issue # 2 Usando FQDN para resolver el problema anterior, todo funciona si uso la versión actual del cliente OpenSSH que es OpenSSH_6.1. El cliente OpenSSH_5.8p2 en mi sistema FreeBSD puede encontrar los registros SSHFP para un nuevo servidor OpenSSH_6.1, pero no puede hacer coincidir la huella digital que recibe del DNS con la que recibe del servidor. El cliente OpenSSH_5.9p1 en mi máquina con OS X 10.8.2 ni siquiera puede recuperar los registros SSHFP para un nuevo servidor OpenSSH_6.1 a pesar de ser una versión nunca del cliente que la máquina FreeBSD. Obviamente, no puede hacer coincidir los registros SSHFP no existentes con la huella digital devuelta por el servidor OpenSSH. Por último, ssh-keygen en el cuadro de FreeBSD produce malos registros SSHFP de acuerdo con los clientes OpenSSH_6.1 que se quejan de un ataque MITM ya que no ' t coincide con la huella digital devuelta por el servidor La solución parece ser que debe ejecutar la versión actual del cliente y servidor OpenSSH para que SSHFP funcione. Usar una versión anterior del cliente o del servidor es pedir problemas.

Reflexiones finales El uso de SSHFP con DNS aparentemente es demasiado avanzado para ser utilizado en un entorno de sistema operativo mixto y tiene todo "simplemente funciona", ya que los sistemas operativos que no son de OpenBSD tienen que portar OpenSSH portátil que está desactualizado para cuando se porta. Quizás en 3-5 años, SSHFP será lo suficientemente estable como para que incluso las versiones anteriores que se transfieren a otros sistemas operativos también sean estables y compatibles con la última versión.

El nombre de host del servidor al que se conecta SSH debe coincidir exactamente con el nombre de host en el registro SSHFP. Es decir, no es suficiente que los dos nombres de host se resuelvan en la misma dirección IP. Por lo tanto, ssh wwwno funcionará para SSHFP que sean para www.test.us., a menos que www esté en su configuración de SSH de esta manera:

Host www
    Hostname www.test.us

Tratar ssh www.test.us.

Debe proporcionar el nombre de archivo de la clave pública del servicio para el que está creando registros DNS. De lo contrario, usará su (s) archivo (s) de clave pública personal de .ssh / *. Pub como reserva predeterminada.

ssh-keygen -r vm1.test.us -f /etc/ssh/ssh_host_rsa_key.pub