Конфигурирование ssh-отпечатков пальцев на днс для замены known_hosts завершается ошибкой

Записи SSHFP были созданы на сервере ssh следующим образом, а затем добавлены в зону в привязке:

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

Требуемые записи можно получить из клиента ssh через DNS, как показано ниже:

$ 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

Однако ssh на клиенте не может найти их при подключении:

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

Есть идеи, почему это не удается? Я знаю, что DNSSEC требуется, чтобы сделать его безопасным, и что я должен получить предупреждение, поскольку DNSSEC в настоящее время не включен. Я надеюсь заставить это работать без DNSSEC, прежде чем я начну рассматривать это как дополнительную проблему.

Сервер ssh является FreeBSD 9.1 с OpenSSH_5.8p2_hpn13v11 и также размещает DNS с использованием BIND 9.8.3-P4. Я пытался подключиться из OS X 10.8.2 с OpenSSH_5.9p1, а также Arch Linux 3.6.10-1-ARCH с OpenSSH_6.1p1.

Обновить

В дальнейших попытках решить эту проблему я установил новую виртуальную машину OpenBSD 5.2, в которую встроен OpenSSH_6.1 в качестве ssh-сервера. Поскольку все другие реализации сервера OpenSSH являются просто портами OpenBSD, это, безусловно, должно работать. На сервере я генерирую записи 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

Я добавляю их на сервер привязки FreeBSD и перезагружаю их. Затем проверьте, могу ли я получить доступ к записям:

$ 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

Записи явно обслуживаются через DNS, поэтому я пытаюсь использовать 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)? 

На данный момент, я думаю, что безопасно устранять ssh-клиенты и серверы как точку отказа. Вместо этого я собираюсь сосредоточить внимание на DNS-сервере. Если у кого-то нет предложений, где искать, я думаю, что я застрял с захватом пакетов и копанием в них, чтобы найти подсказки.

Update2

Хорошо, вот результаты моих захватов пакетов. SSH WWW; терпит неудачу со стандартом

No matching host key fingerprint found in DNS.

и захват пакета показывает, что DNS не может вернуть запись для поиска.

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

Сравните с ssh www.test.us; что также не с сообщением

No matching host key fingerprint found in DNS.

однако захват пакета показывает, что DNS фактически возвращает запись.

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`

Во-первых, немного смущает, что сообщение об ошибке одинаково для обоих случаев. Я могу добавить некоторые записи, чтобы исправить случай 1, когда записи не возвращаются, но большая проблема - это случай 2. DNS работает, и записи SSHFP возвращаются клиенту ssh. После ответа на запрос DNS пакеты не отправляются, и клиент ssh немедленно отображает сообщение о несоответствии отпечатков пальцев. Это означает, что либо все клиенты ssh, с которыми я тестирую, повреждены, либо отпечатки пальцев, хранящиеся в DNS, неверны и не совпадают. Я сомневаюсь, что это клиенты, так почему отпечатки пальцев в DNS неверны? Отпечатки были сгенерированы из встроенных в ssh инструментов ssh-keygen, как описано в самом начале этого поста. Также проблема не в том, что отпечатки пальцев отображаются в разных форматах в зависимости от контекста.

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

Кто-нибудь есть какие-либо предложения относительно того, почему вывод отпечатков пальцев из ssh-keygen -r не совпадает с открытыми ключами, возвращенными тем же сервером ssh?

Update3

Я дошел до моего последнего варианта. Если кто-то не укажет мне правильное направление перед выходными, я проведу субботу, создавая дублирующую среду с использованием виртуальных машин, полностью основанных на OpenBSD. Поскольку OpenBSD владеет OpenSSH, это должно быть идеальными условиями для работы SSHFP через DNS. Если сервер OpenBSD OpenSSH с привязкой, обслуживающий клиента OpenBSD OpenSSH, не работает, то SSHFP не работает, как реализовано, и я перенесу вещи на форумы OpenBSD и, возможно, отправлю сообщение об ошибке. Я все еще надеюсь, что упускаю что-то очевидное и что полезный ответ спасет мои выходные.

Видимо мои проблемы были вызваны двумя разными проблемами.

Проблема № 1 SSHFP не поддерживает использование путей поиска. Так что, если вы добавите «domain example.com» в /etc/resolv.conf, вы ожидаете, что ssh myhost будет работать с SSHFP, поскольку обычный ssh ​​правильно разрешит имя myhost.example.com. Очевидно, разработчики OpenBSD знают об этой проблеме, так как патч был выпущен 2 года назад, но никогда не применялся. Вместо этого был предложен взлом ssh_config, но он тоже не работает. Таким образом, решение первой проблемы заключается в том, что полное доменное имя всегда должно использоваться с SSHFP.

Выпуск № 2 Используя полные доменные имена для решения предыдущей проблемы, все работает, если я использую текущую версию клиента OpenSSH, которая является OpenSSH_6.1. Клиент OpenSSH_5.8p2 в моей системе FreeBSD может найти записи SSHFP для нового сервера OpenSSH_6.1, но он не может сопоставить отпечаток, полученный с DNS, с отпечатком, полученным с сервера. Клиент OpenSSH_5.9p1 на моем компьютере с OS X 10.8.2 не может даже извлечь записи SSHFP для нового сервера OpenSSH_6.1, несмотря на то, что он никогда не был версией клиента, чем машина FreeBSD. Очевидно, что он не может сопоставить несуществующие записи SSHFP с отпечатком, возвращенным сервером OpenSSH. Наконец, ssh-keygen на коробке FreeBSD создает плохие записи SSHFP в соответствии с клиентами OpenSSH_6.1, которые жалуются на атаку MITM, так как они не не соответствует отпечатку, возвращенному сервером. Решение заключается в том, что для работы SSHFP необходимо запустить текущую версию клиента и сервера OpenSSH. Использование более старой версии клиента или сервера вызывает проблемы.

Заключительные мысли Использование SSHFP с DNS, по-видимому, слишком современно, чтобы его можно было использовать в смешанной среде ОС, и все работает "просто так", поскольку ОС, не являющиеся OpenBSD, должны переносить OpenSSH portable, который устарел к моменту портирования. Возможно, через 3-5 лет SSHFP будет достаточно стабильным, так что даже более старые версии, перенесенные на другие ОС, будут также стабильны и совместимы с последней версией.

Имя хоста сервера, к которому подключается SSH, должно точно соответствовать имени хоста в записи SSHFP. То есть недостаточно просто разрешить двум именам хостов один и тот же IP-адрес. Таким образом, ssh wwwне будет работать для SSHFP, которые предназначены для www.test.us., если www не в вашей конфигурации SSH, как это:

Host www
    Hostname www.test.us

Попробуй ssh www.test.us.

Вам необходимо указать имя файла открытого ключа службы, для которой вы создаете записи DNS. В противном случае он будет использовать ваши личные файлы открытого ключа из .ssh / *. Pub как запасной вариант по умолчанию.

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