Mengonfigurasi sidik jari ssh pada dns untuk mengganti diketahui_host gagal

Catatan SSHFP dihasilkan di server ssh sebagai berikut dan kemudian ditambahkan ke zona di bind:

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

Catatan yang diperlukan dapat diambil dari klien ssh melalui DNS seperti yang ditunjukkan:

$ 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

Namun ssh pada klien gagal menemukannya saat menghubungkan:

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

Ada ide mengapa ini gagal? Saya tahu bahwa DNSSEC diperlukan untuk membuatnya aman dan saya harus mendapatkan peringatan karena DNSSEC saat ini tidak diaktifkan. Saya berharap ini berfungsi tanpa DNSSEC terlebih dahulu sebelum saya mulai menangani itu sebagai masalah tambahan.

Server ssh adalah FreeBSD 9.1 dengan OpenSSH_5.8p2_hpn13v11 dan juga hosting DNS menggunakan BIND 9.8.3-P4. Saya sudah mencoba menghubungkan dari OS X 10.8.2 dengan OpenSSH_5.9p1 serta Arch Linux 3.6.10-1-ARCH dengan OpenSSH_6.1p1.

Memperbarui

Dalam upaya lebih lanjut untuk memecahkan masalah ini, saya berdiri VM OpenBSD 5.2 baru yang memiliki OpenSSH_6.1 dibangun ke dalamnya sebagai server ssh. Karena semua implementasi lain dari server OpenSSH hanyalah port-port dari OpenBSD, pasti ini akan berfungsi. Di server saya menghasilkan catatan 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

Saya menambahkannya ke server mengikat FreeBSD dan memuat ulang bernama. Kemudian uji untuk melihat apakah saya dapat mengakses catatan:

$ 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

Catatan jelas dilayani melalui DNS, jadi saya mencoba menggunakan 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)? 

Pada titik ini, saya pikir aman untuk menghilangkan klien dan server ssh sebagai titik kegagalan. Sebaliknya saya akan memfokuskan server DNS. Kecuali seseorang memiliki saran tentang ke mana harus mencari, saya kira saya terjebak dengan mengambil tangkapan paket dan menggali melalui mereka untuk menemukan petunjuk.

Pembaruan2

Oke, inilah hasil tangkapan paket saya. ssh www; gagal dengan standar

No matching host key fingerprint found in DNS.

dan penangkapan paket menunjukkan bahwa DNS gagal mengembalikan catatan untuk pencarian.

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

Bandingkan dengan ssh www.test.us; yang juga gagal dengan pesan

No matching host key fingerprint found in DNS.

Namun penangkapan paket menunjukkan bahwa DNS benar-benar mengembalikan catatan.

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`

Pertama, agak membingungkan bahwa pesan kesalahannya sama untuk kedua kasus. Saya dapat menambahkan beberapa catatan untuk memperbaiki kasus 1 di mana tidak ada catatan dikembalikan, tetapi masalah besar adalah kasus 2. DNS bekerja dan catatan SSHFP dikembalikan ke klien ssh. Tidak ada paket yang dikirim setelah respons permintaan DNS dan klien ssh segera menampilkan pesan sidik jari yang tidak cocok. Ini berarti semua klien ssh yang saya uji rusak atau sidik jari yang disimpan dalam DNS salah dan tidak cocok. Saya ragu itu adalah klien jadi mengapa sidik jari di DNS salah? Sidik jari dihasilkan dari alat ssh ssh-keygen bawaan seperti yang dijelaskan pada awal posting ini. Juga, masalahnya tidak terbantu oleh fakta bahwa sidik jari ditampilkan dalam format berbeda tergantung pada konteksnya.

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

Adakah yang punya saran mengapa sidik jari dihasilkan dari ssh-keygen -r tidak cocok dengan kunci publik yang dikembalikan oleh server ssh yang sama?

Pembaruan3

Saya turun ke opsi terakhir saya. Kecuali seseorang menunjuk saya ke arah yang benar sebelum akhir pekan, saya akan menghabiskan hari Sabtu saya membuat lingkungan duplikat menggunakan VM yang sepenuhnya berbasis OpenBSD. Karena OpenBSD memiliki OpenSSH, ini harus menjadi kondisi ideal untuk SSHFP agar DNS dapat berfungsi. Jika server OpenBSD OpenSSH dengan bind yang melayani klien OpenBSD OpenSSH tidak berfungsi, maka SSHFP rusak seperti yang diterapkan dan saya akan memindahkan sesuatu ke forum OpenBSD dan mungkin mengajukan laporan bug. Saya masih berharap bahwa saya kehilangan sesuatu yang jelas dan bahwa balasan yang membantu akan menyelamatkan akhir pekan saya.

Rupanya masalah saya disebabkan oleh dua masalah yang berbeda.

Masalah # 1 SSHFP tidak mendukung menggunakan jalur pencarian. Jadi, jika Anda menambahkan "domain example.com" ke /etc/resolv.conf maka Anda akan mengharapkan ssh myhost untuk bekerja dengan SSHFP karena ssh biasa akan dengan benar menyelesaikan nama ke myhost.example.com. Rupanya para pengembang OpenBSD mengetahui masalah ini sejak sebuah patch dikeluarkan 2 tahun yang lalu tetapi tidak pernah diterapkan. Alih-alih sebuah ssh_config disarankan, tetapi itu tampaknya tidak berhasil. Jadi solusi untuk masalah pertama adalah FQDN harus selalu digunakan dengan SSHFP.

Edisi # 2 Menggunakan FQDN untuk menyelesaikan masalah sebelumnya, semuanya berfungsi jika saya menggunakan versi klien OpenSSH saat ini yaitu OpenSSH_6.1. Klien OpenSSH_5.8p2 pada sistem FreeBSD saya dapat menemukan catatan SSHFP untuk server OpenSSH_6.1 baru, tetapi tidak dapat mencocokkan sidik jari yang diterimanya dari DNS dengan yang diterima dari server. Klien OpenSSH_5.9p1 pada mesin OS X 10.8.2 saya bahkan tidak dapat mengambil catatan SSHFP untuk server OpenSSH_6.1 baru meskipun versi klien tidak pernah dibandingkan dengan mesin FreeBSD. Jelas itu tidak dapat mencocokkan catatan SSHFP yang tidak ada dengan sidik jari yang dikembalikan oleh server OpenSSH. Terakhir, ssh-keygen pada kotak FreeBSD menghasilkan catatan SSHFP yang buruk menurut OpenSSH_6.1 klien yang mengeluh tentang serangan MITM karena mereka tidak t cocok dengan sidik jari yang dikembalikan oleh server. Solusinya adalah Anda harus menjalankan versi klien dan server OpenSSH saat ini agar SSHFP dapat berfungsi. Menggunakan versi yang lebih lama baik dari klien atau server meminta masalah.

Pikiran Final Menggunakan SSHFP dengan DNS tampaknya terlalu canggih untuk digunakan dalam lingkungan OS campuran dan memiliki segalanya "hanya berfungsi" karena OS non-OpenBSD harus mem-porting portable OpenSSH yang ketinggalan zaman pada saat porting. Mungkin dalam 3-5yrs, SSHFP akan cukup stabil sehingga bahkan versi lama yang porting ke OS lain juga akan stabil dan kompatibel dengan versi terbaru.

Nama host server yang disambungkan SSH harus sama persis dengan nama host dalam catatan SSHFP. Artinya, tidak cukup hanya bagi kedua nama host untuk menyelesaikan ke alamat IP yang sama. Dengan demikian, ssh wwwtidak akan berfungsi untuk SSHFP untuk www.test.us., kecuali www ada di konfigurasi SSH Anda seperti ini:

Host www
    Hostname www.test.us

Coba ssh www.test.us.

Anda harus menyediakan nama file kunci publik dari layanan yang Anda buat data DNSnya. Kalau tidak, ia akan menggunakan file kunci publik pribadi Anda dari .ssh / *. Pub sebagai fallback default.

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