Не вдалося налаштувати ssh відбитки пальців на dns для заміни відомих_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 VM, в який вбудований 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. Якщо хтось не пропонує, де його шукати, я думаю, я застряг із захопленням пакетів і захоплюючи їх, щоб знайти підказки.

Оновлення2

Гаразд, ось результати моїх пакетних захоплень. 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 сервером?

Оновлення3

Я переживаю свій останній варіант. Якщо хтось не вкаже мене в правильному напрямку перед вихідними, я проведу свою суботу, створюючи дублююче середовище, використовуючи VM, засновані повністю на OpenBSD. Оскільки OpenBSD є власником OpenSSH, це повинно бути ідеальними умовами для роботи SSHFP над DNS. Якщо сервер OpenBSD OpenSSH з прив’язкою, що обслуговує клієнт OpenBSD, не працює, тоді SSHFP порушується, як реалізовано, і я переміщу речі на форуми OpenBSD і, можливо, подати звіт про помилки. Я все ще сподіваюся, що я пропускаю щось очевидне і що корисна відповідь врятує мої вихідні.

Мабуть, мої проблеми були викликані двома різними проблемами.

Випуск №1 SSHFP не підтримує використання шляхів пошуку. Отже, якщо ви додасте "domain example.com" в /etc/resolv.conf, тоді ви очікуєте, що ssh myhost працюватиме з SSHFP, оскільки звичайний ssh ​​правильно вирішить ім'я на myhost.example.com. Мабуть, розробники OpenBSD знають про проблему, оскільки патч був виданий 2 роки тому, але він ніколи не застосовувався. Натомість було запропоновано зламати ssh_config, але це, здається, також не працює. Тому рішення першого питання полягає в тому, що FQDN завжди повинен використовуватися з SSHFP.

Випуск №2 Використовуючи FQDN для вирішення попередньої проблеми, все працює, якщо я використовую поточну версію клієнта 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, оскільки вони не роблять ' t відповідь відбитків, повернутих сервером. Рішення полягає в тому, що для запуску SSHFP потрібно запустити поточну версію клієнта OpenSSH і сервера. Використання старішої версії або клієнта, або сервера вимагає неприємностей.

Заключні думки Використання SSHFP з DNS, мабуть, занадто передній край, щоб використовувати його в змішаному середовищі ОС, і все "просто працює", оскільки не-OpenBSD ОС повинні переносити OpenSSH портативний, який застарілий до моменту його порту. Можливо, через 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