La configurazione delle impronte digitali ssh su dns per sostituire known_hosts non riesce

I record SSHFP sono stati generati sul server ssh come segue e quindi aggiunti alla zona in bind:

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

I record richiesti possono essere acquisiti dal client ssh tramite DNS come mostrato:

$ 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

Tuttavia ssh sul client non riesce a trovarli durante la connessione:

$ 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)?

Qualche idea sul perché questo stia fallendo? So che DNSSEC è necessario per renderlo sicuro e che dovrei ricevere un avviso poiché DNSSEC non è attualmente abilitato. Spero di farlo funzionare senza DNSSEC prima di iniziare ad affrontarlo come un ulteriore problema.

Il server SSH è FreeBSD 9.1 con OpenSSH_5.8p2_hpn13v11 e ospita anche DNS usando BIND 9.8.3-P4. Ho provato a collegarmi da OS X 10.8.2 con OpenSSH_5.9p1 e Arch Linux 3.6.10-1-ARCH con OpenSSH_6.1p1.

Aggiornare

In un ulteriore tentativo di risolvere questo problema, ho creato una nuova VM OpenBSD 5.2 con OpenSSH_6.1 integrato come server SSH. Poiché tutte le altre implementazioni del server OpenSSH sono solo porte di OpenBSD, sicuramente dovrebbe funzionare. Sul server ho generato i record 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

Li aggiungo al server di bind di FreeBSD e ricarico con nome. Quindi prova per vedere se riesco ad accedere ai record:

$ 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

I record vengono chiaramente pubblicati su DNS, quindi provo a usare 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)? 

A questo punto, penso che sia sicuro eliminare i client e i server SSH come punto di errore. Invece focalizzerò il server DNS. A meno che qualcuno non abbia un suggerimento su dove cercare, immagino di essere bloccato nel prendere i pacchetti catturati e scavare attraverso di essi per trovare indizi.

Update2

Ok, ecco i risultati delle mie acquisizioni di pacchetti. ssh www; fallisce con lo standard

No matching host key fingerprint found in DNS.

e l'acquisizione di pacchetti mostra che DNS non riesce a restituire un record per la ricerca.

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

Confronta con ssh www.test.us; che fallisce anche con il messaggio

No matching host key fingerprint found in DNS.

tuttavia l'acquisizione di pacchetti mostra che DNS restituisce effettivamente il record.

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`

Innanzitutto, è un po 'sconcertante che il messaggio di errore sia lo stesso per entrambi i casi. Posso aggiungere alcuni record per correggere il caso 1 in cui non vengono restituiti record, ma il grosso problema è il caso 2. Il DNS funziona e i record SSHFP vengono restituiti al client SSH. Nessun pacchetto viene inviato dopo la risposta alla query DNS e il client ssh visualizza immediatamente il messaggio di nessuna impronta digitale corrispondente. Questo significa che tutti i client SSH con cui sto testando sono rotti o l'impronta digitale memorizzata nel DNS è errata e non corrisponde. Dubito che siano i clienti, quindi perché l'impronta digitale nel DNS è sbagliata? Le impronte digitali sono state generate dagli strumenti ssh integrati ssh-keygen come descritto all'inizio di questo post. Inoltre, il problema non è aiutato dal fatto che le impronte digitali sono visualizzate in diversi formati a seconda del contesto.

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

Qualcuno ha qualche suggerimento sul perché le impronte digitali emesse da ssh-keygen -r non corrispondono alle chiavi pubbliche restituite dallo stesso server ssh?

Update3

Sono arrivato alla mia ultima opzione. A meno che qualcuno non mi indichi nella giusta direzione prima del fine settimana, passerò il mio sabato a creare un ambiente duplicato usando macchine virtuali completamente basate su OpenBSD. Poiché OpenBSD possiede OpenSSH, queste dovrebbero essere le condizioni ideali per far funzionare SSHFP su DNS. Se un server OpenSSD OpenSSD con bind che serve un client OpenSSD OpenSSD non funziona, allora SSHFP viene interrotto come implementato e sposterò le cose sui forum OpenBSD e, eventualmente, presenterò una segnalazione di bug. Spero ancora che mi manchi qualcosa di ovvio e che una risposta utile salverà il mio fine settimana.

Apparentemente i miei problemi sono stati causati da due diversi problemi.

Problema n. 1 SSHFP non supporta l'utilizzo dei percorsi di ricerca. Quindi se aggiungi "domain example.com" a /etc/resolv.conf, ti aspetteresti che ssh myhost funzioni con SSHFP poiché ssh normale risolverà correttamente il nome in myhost.example.com. Apparentemente gli sviluppatori OpenBSD sono a conoscenza del problema da quando una patch è stata rilasciata 2 anni fa ma non è mai stata applicata. Invece è stato suggerito un hack di ssh_config ma neanche quello sembra funzionare. Quindi la soluzione al primo problema è che il nome di dominio completo deve essere sempre utilizzato con SSHFP.

Numero 2 Utilizzando i nomi di dominio completi per risolvere il problema precedente, tutto funziona se utilizzo la versione corrente del client OpenSSH che è OpenSSH_6.1. Il client OpenSSH_5.8p2 sul mio sistema FreeBSD è in grado di trovare i record SSHFP per un nuovo server OpenSSH_6.1, ma non è in grado di abbinare l'impronta digitale che riceve dal DNS con quella che riceve dal server. Il client OpenSSH_5.9p1 sul mio computer OS X 10.8.2 non è nemmeno in grado di recuperare i record SSHFP per un nuovo server OpenSSH_6.1 nonostante sia una versione mai del client rispetto al computer FreeBSD. Ovviamente non è possibile abbinare i record SSHFP inesistenti con l'impronta digitale restituita dal server OpenSSH. Infine, ssh-keygen sulla casella FreeBSD produce record SSHFP errati secondo i client OpenSSH_6.1 che si lamentano di un attacco MITM poiché non t corrisponde all'impronta digitale restituita dal server. La soluzione sembra essere che è necessario eseguire la versione corrente del client e del server OpenSSH affinché SSHFP funzioni. L'uso di una versione precedente del client o del server richiede problemi.

Considerazioni finali L' uso di SSHFP con DNS è apparentemente troppo all'avanguardia per essere utilizzato in un ambiente di sistema operativo misto e avere tutto "solo funzionante" poiché i sistemi operativi non OpenBSD devono eseguire il porting di OpenSSH portatile che non è aggiornato al momento del porting. Forse tra 3-5 anni, SSHFP sarà abbastanza stabile che anche le versioni precedenti portate su altri sistemi operativi saranno stabili e compatibili con l'ultima versione.

Il nome host del server a cui si connette SSH deve corrispondere esattamente al nome host nel record SSHFP. In altre parole, non è sufficiente che i due nomi host si risolvano nello stesso indirizzo IP. Pertanto, ssh wwwnon funzionerà per SSHFP che sono per www.test.us., a meno che www non sia nella tua configurazione SSH in questo modo:

Host www
    Hostname www.test.us

Prova ssh www.test.us.

È necessario fornire il nome file della chiave pubblica del servizio per cui si stanno creando record DNS. Altrimenti utilizzerà i file delle chiavi pubbliche personali di .ssh / *. Pub come fallback predefinito.

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