A configuração de impressões digitais ssh no dns para substituir o known_hosts falha

Question

Os registros SSHFP foram gerados no servidor ssh da seguinte forma e, em seguida, adicionados à zona em associação:

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

Os registros necessários podem ser obtidos do cliente ssh via DNS, conforme mostrado:

$ 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

No entanto, o ssh no cliente não consegue encontrá-los quando 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)?

Alguma idéia de por que isso está falhando? Eu sei que o DNSSEC é necessário para torná-lo seguro e que devo receber um aviso, pois o DNSSEC não está habilitado no momento. Espero conseguir que isso funcione sem DNSSEC antes de começar a lidar com isso como um problema adicional.

O servidor ssh é o FreeBSD 9.1 com OpenSSH_5.8p2_hpn13v11 e também hospeda DNS usando o BIND 9.8.3-P4. Eu tentei conectar do OS X 10.8.2 com o OpenSSH_5.9p1, bem como com o Arch Linux 3.6.10-1-ARCH com o OpenSSH_6.1p1.

Atualizar

Em mais uma tentativa de solucionar isso, levantei uma nova VM do OpenBSD 5.2 que possui o OpenSSH_6.1 como servidor ssh. Como todas as outras implementações do servidor OpenSSH são apenas portas do OpenBSD, certamente isso deve funcionar. No servidor, eu gero os registros do 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

Eu os adiciono ao servidor de bind do FreeBSD e recarrego o named. Em seguida, teste para ver se consigo acessar os 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

Os registros estão claramente sendo veiculados pelo DNS, então eu tento usar o 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)? 

Neste ponto, acho que é seguro eliminar os clientes e servidores ssh como ponto de falha. Em vez disso, vou focar o servidor DNS. A menos que alguém tenha uma sugestão de onde procurar, acho que estou presa em capturar pacotes e cavar através deles para encontrar pistas.

Update2

Ok, aqui estão os resultados das minhas capturas de pacotes. ssh www; falha com o padrão

No matching host key fingerprint found in DNS.

e a captura de pacotes mostra que o DNS não retorna um registro para a pesquisa.

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

Compare com ssh www.test.us; que também falha com a mensagem

No matching host key fingerprint found in DNS.

no entanto, a captura de pacotes mostra que o DNS realmente retorna o 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'

Primeiro, é um pouco desconcertante que a mensagem de erro seja a mesma para os dois casos. Eu posso adicionar alguns registros para corrigir o caso 1, onde nenhum registro é retornado, mas o grande problema é o caso 2. O DNS funciona e os registros do SSHFP estão sendo retornados para o cliente ssh. Nenhum pacote é enviado após a resposta da consulta DNS e o cliente ssh exibe imediatamente a mensagem sem impressão digital correspondente. Isso significa que todos os clientes ssh com os quais estou testando estão corrompidos ou a impressão digital armazenada no DNS está incorreta e não corresponde. Eu duvido que sejam os clientes, então por que a impressão digital no DNS está errada? As impressões digitais foram geradas a partir das ferramentas ssh construídas em ssh-keygen, conforme descrito no início deste post. Além disso, o problema não é ajudado pelo fato de que as impressões digitais são exibidas em diferentes formatos, dependendo do contexto. Se eles fossem exibidos no mesmo formato, seria fácil ver que o registro armazenado no DNS não é o mesmo que a impressão digital da chave retornada pelo servidor ssh que está sendo conectado.

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

Alguém tem alguma sugestão sobre por que as impressões digitais de ssh-keygen -r não correspondem às chaves públicas retornadas pelo mesmo servidor ssh?

Update3

Estou na minha última opção. A menos que alguém me aponte na direção certa antes do fim de semana, passarei meu sábado criando um ambiente duplicado usando VMs que é completamente baseado no OpenBSD. Como o OpenBSD possui o OpenSSH, isso deve ser uma condição ideal para que o SSHFP sobre o DNS funcione. Se um servidor OpenSSD OpenSSH com bind servindo um cliente OpenSSD OpenSSH não funcionar, então o SSHFP está quebrado como implementado e eu transferirei as coisas para os fóruns do OpenBSD e possivelmente arquive um relatório de erros. Ainda espero que esteja faltando algo óbvio e que uma resposta útil salve meu final de semana.

    

Answer 1

Aparentemente, meus problemas foram causados por dois problemas diferentes.

Problema nº 1 O SSHFP não suporta o uso de caminhos de pesquisa. Então, se você adicionar "domain example.com" ao /etc/resolv.conf, então você esperaria que o ssh myhost trabalhe com o SSHFP, já que o ssh regular irá resolver corretamente o nome para myhost.example.com. Aparentemente, os desenvolvedores do OpenBSD estão cientes do problema desde que um patch foi lançado há 2 anos, mas nunca foi aplicado. Em vez disso, um hack ssh_config foi sugerido, mas também não parece funcionar. Portanto, a solução para o primeiro problema é que o FQDN sempre deve ser usado com o SSHFP.

Problema nº 2 Usando FQDNs para resolver o problema anterior, tudo funciona se eu usar a versão atual do cliente OpenSSH que é OpenSSH_6.1. O cliente OpenSSH_5.8p2 no meu sistema FreeBSD é capaz de encontrar os registros SSHFP para um novo servidor OpenSSH_6.1, mas não é capaz de igualar a impressão digital que recebe do DNS com a que recebe do servidor. O cliente OpenSSH_5.9p1 na minha máquina OS X 10.8.2 não consegue nem recuperar os registros SSHFP para um novo servidor OpenSSH_6.1, apesar de nunca ter sido uma versão do cliente que a máquina FreeBSD. Obviamente, não é possível corresponder os registros SSHFP inexistentes com a impressão digital retornada pelo servidor OpenSSH. Por fim, ssh-keygen na caixa FreeBSD produz registros SSHFP ruins de acordo com os clientes OpenSSH_6.1 que reclamam de um ataque MITM, uma vez que não correspondem à impressão digital retornada pelo servidor. A solução parece ser que você deve executar a versão atual do cliente e do servidor OpenSSH para que o SSHFP funcione. Usar uma versão mais antiga do cliente ou do servidor está causando problemas.

Considerações finais Usar o SSHFP com DNS é aparentemente muito inovador para ser usado em um ambiente de SO misto e ter tudo "apenas trabalho", já que os SOs que não são do OpenBSD precisam portar o OpenSSH portável, que está desatualizado no momento em que é portado. Talvez em 3-5 anos, o SSHFP será estável o suficiente para que até mesmo as versões mais antigas que são portadas para outros sistemas operacionais também sejam estáveis e compatíveis com a versão mais recente.

    

Answer 2

O nome do host do servidor ao qual o SSH está se conectando deve corresponder exatamente ao nome do host no registro SSHFP. Ou seja, não é suficiente apenas que os dois nomes de host resolvam para o mesmo endereço IP. Portanto, ssh www não funcionará para SSHFPs que são para www.test.us., a menos que www esteja em sua configuração de SSH da seguinte forma:

Host www
    Hostname www.test.us

Experimente ssh www.test.us .

    

Answer 3

Você precisa fornecer o nome do arquivo da chave pública do serviço para o qual você está criando registros DNS. Caso contrário, ele usará seus arquivos de chave pública pessoal de .ssh / *. Pub como alternativa padrão.

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