Os registros SSHFP foram gerados no servidor ssh da seguinte forma e adicionados à zona na ligaçã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, como 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 falha ao encontrá-los ao conectar:
$ 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? Sei que o DNSSEC é necessário para torná-lo seguro e que devo receber um aviso, pois o DNSSEC não está ativado no momento. Espero que isso funcione sem o DNSSEC antes de começar a abordar 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 me conectar do OS X 10.8.2 com o OpenSSH_5.9p1, bem como do Arch Linux 3.6.10-1-ARCH com o OpenSSH_6.1p1.
Atualizar
Em uma tentativa adicional de solucionar isso, levantei uma nova VM do OpenBSD 5.2 que possui o OpenSSH_6.1 embutido como um servidor ssh. Como todas as outras implementações do servidor OpenSSH são apenas portas do OpenBSD, certamente isso deve funcionar. No servidor, eu giro os 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
Eu os adiciono ao servidor de ligação do FreeBSD e recarrego o nome. 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 sendo claramente exibidos no DNS, então 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 o ponto de falha. Em vez disso, vou focar no servidor DNS. A menos que alguém tenha uma sugestão de onde procurar, acho que estou preso em capturar pacotes e vasculhá-los 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 falha ao retornar 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 nos dois casos. 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 SSHFP estão sendo retornados ao cliente ssh. Nenhum pacote é enviado após a resposta da consulta DNS e o cliente ssh exibe imediatamente a mensagem de impressão digital sem correspondência. Isso significa que todos os clientes ssh com os quais estou testando estão com problemas ou a impressão digital armazenada no DNS está errada e não corresponde. Duvido que sejam os clientes, por que a impressão digital no DNS está errada? As impressões digitais foram geradas a partir do ssh tools ssh-keygen, conforme descrito no início deste post. Além disso, o problema não é ajudado pelo fato de as impressões digitais serem exibidas em diferentes formatos, dependendo do 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
Alguém tem alguma sugestão de por que as impressões digitais geradas pelo 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 final de semana, passarei meu sábado criando um ambiente duplicado usando VMs totalmente baseadas em OpenBSD. Como o OpenBSD possui o OpenSSH, isso teria que ser condições ideais para o SSHFP sobre DNS funcionar. Se um servidor OpenBSD OpenSSH com bind atendendo a um cliente OpenBSD OpenSSH não funcionar, o SSHFP será quebrado conforme implementado e eu moverei as coisas para os fóruns do OpenBSD e, possivelmente, apresentarei um relatório de erro. Ainda espero que esteja perdendo algo óbvio e que uma resposta útil salve meu fim de semana.
www.test.us?sshconfuso com os registros DNS que não correspondem ao nome do host que você está tentando acessar.Respostas:
Aparentemente, meus problemas foram causados por dois problemas diferentes.
Problema nº 1 O SSHFP não oferece suporte ao uso de caminhos de pesquisa. Portanto, se você adicionar "domain example.com" ao /etc/resolv.conf, esperaria que o ssh myhost funcionasse com o SSHFP, já que o ssh regular 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, foi sugerido um hack ssh_config, mas isso também não parece funcionar. Portanto, a solução para o primeiro problema é que o FQDN sempre deve ser usado com o SSHFP.
Edição 2 Usando FQDNs para resolver o problema anterior, tudo funcionará se eu usar a versão atual do cliente OpenSSH, que é o OpenSSH_6.1. O cliente OpenSSH_5.8p2 no meu sistema FreeBSD pode encontrar os registros SSHFP para um novo servidor OpenSSH_6.1, mas não consegue corresponder 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 recuperar os registros SSHFP para um novo servidor OpenSSH_6.1, apesar de nunca ser uma versão do cliente que a máquina FreeBSD. Obviamente, é incapaz de corresponder os registros SSHFP inexistentes com a impressão digital retornada pelo servidor OpenSSH. Por fim, o ssh-keygen na caixa do FreeBSD produz registros SSHFP ruins, de acordo com os clientes OpenSSH_6.1, que reclamam de um ataque MITM, pois não t corresponde à impressão digital retornada pelo servidor. A solução parece ser que você deve executar a versão atual do cliente e servidor OpenSSH para que o SSHFP funcione. O uso de uma versão mais antiga do cliente ou do servidor está causando problemas.
Considerações finais O uso do SSHFP com DNS é aparentemente muito avançado para ser usado em um ambiente de sistema operacional misto e ter tudo "simplesmente funcionado", pois os sistemas operacionais não-OpenBSD precisam portar o OpenSSH portable, que está desatualizado no momento em que é portado. Talvez em 3 a 5 anos, o SSHFP seja estável o suficiente para que mesmo as versões mais antigas portadas para outros sistemas operacionais também sejam estáveis e compatíveis com a versão mais recente.
fonte
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 para os dois nomes de host resolverem o mesmo endereço IP. Portanto,
ssh wwwnão funcionará para SSHFP's que são para www.test.us., a menos que www esteja na sua configuração SSH como esta:Tente
ssh www.test.us.fonte
Você precisa fornecer o nome do arquivo da chave pública do serviço para o qual está criando registros DNS. Caso contrário, ele usará seu (s) arquivo (s) de chave pública pessoal de .ssh / *. Pub como fallback padrão.
fonte