Bilinen_hosts yerine ssh parmak izlerini yapılandırma başarısız oluyor

SSHFP kayıtları ssh sunucusunda aşağıdaki gibi oluşturuldu ve sonra bağlamadaki bölgeye eklendi:

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

Gerekli kayıtlar gösterildiği gibi ssh istemcisinden DNS üzerinden alınabilir:

$ 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

Ancak istemcideki ssh bağlanırken onları bulamıyor:

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

Bunun neden başarısız olduğuna dair herhangi bir fikir var mı? DNSSEC'nin güvenliğini sağlamak için gerekli olduğunu ve DNSSEC'in şu anda etkin olmadığı için bir uyarı almam gerektiğini biliyorum. Ek bir sorun olarak mücadele etmeye başlamadan önce DNSSEC olmadan bu çalışmayı umuyorum.

Ssh sunucusu, OpenSSH_5.8p2_hpn13v11 ile FreeBSD 9.1'dir ve ayrıca BIND 9.8.3-P4 kullanarak DNS barındırmaktadır. OpenSSH_5.9p1 ile OS X 10.8.2 ve OpenSSH_6.1p1 ile Arch Linux 3.6.10-1-ARCH ile bağlanmayı denedim.

Güncelleme

Bu sorunu gidermek için başka bir girişimde, ssh sunucusu olarak OpenSSH_6.1 yerleşik yeni bir OpenBSD 5.2 VM durdu. OpenSSH sunucusunun diğer tüm uygulamaları sadece OpenBSD'nin bağlantı noktaları olduğundan, kesinlikle bu çalışmalıdır. Sunucuda SSHFP kayıtlarını oluşturuyorum:

# 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

Onları FreeBSD bağlama sunucusuna ekler ve adlı dosyayı yeniden yüklerim. Sonra ben kayıtları erişip erişemediğini görmek için test edin:

$ 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

Kayıtlar açıkça DNS üzerinden sunuluyor, bu yüzden ssh kullanmaya çalışıyorum:

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

Bu noktada, ssh istemcilerini ve sunucularını hata noktası olarak ortadan kaldırmanın güvenli olduğunu düşünüyorum. Bunun yerine DNS sunucusuna odaklanacağım. Birisi nereye bakacağına dair bir öneriye sahip değilse, sanırım paket yakalama ve ipuçlarını bulmak için onları kazma konusunda sıkıştım.

Update2

Tamam, işte paketlerimin sonuçları. ssh www; standart ile başarısız

No matching host key fingerprint found in DNS.

ve paket yakalama DNS'in arama için bir kayıt döndüremediğini gösterir.

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 ile karşılaştırın; bu da mesajda başarısız oluyor

No matching host key fingerprint found in DNS.

ancak paket yakalama DNS'nin gerçekten kaydı döndürdüğünü gösterir.

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`

İlk olarak, hata mesajının her iki durumda da aynı olması biraz endişe vericidir. Hiçbir kayıt döndürülmediğinde durum 1'i düzeltmek için bazı kayıtlar ekleyebilirim, ancak büyük sorun durum 2'dir. DNS çalışır ve SSHFP kayıtları ssh istemcisine iade edilir. DNS sorgu yanıtından sonra hiçbir paket gönderilmez ve ssh istemcisi eşleşen parmak izi iletisini hemen görüntüler. Bu, test ettiğim tüm ssh istemcilerinin bozuk olduğu veya DNS'de depolanan parmak izinin yanlış olduğu ve eşleşmediği anlamına gelir. Müşteriler olduğundan şüpheliyim, bu yüzden DNS'deki parmak izi neden yanlış? Parmak izleri, bu yazının en başında açıklandığı gibi yerleşik ssh araçları ssh-keygen'den üretildi. Ayrıca, içeriğe bağlı olarak parmak izlerinin farklı formatlarda görüntülenmesi sorunu çözmez.

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

Herkes ssh-keygen -r gelen parmak izleri çıktı aynı ssh sunucusu tarafından döndürülen ortak anahtarları eşleşmiyor herhangi bir öneriniz var mı?

Update3

Son seçeneğime geldim. Birisi hafta sonundan önce beni doğru yöne yönlendirmedikçe, Cumartesi günümü tamamen OpenBSD tabanlı VM'leri kullanarak yinelenen bir ortam oluşturacağım. OpenBSD'nin OpenSSH sahibi olması nedeniyle, bunun DNS üzerinden SSHFP'nin çalışması için ideal koşullar olması gerekir. Bir OpenBSD OpenSSH istemcisi sunan bağlamalı bir OpenBSD OpenSSH sunucusu çalışmazsa, SSHFP uygulandığı gibi bozulur ve işleri OpenBSD forumlarına taşıyacağım ve muhtemelen bir hata raporu dosyalayacağım. Hala bariz bir şeyi kaçırmamı ve yardımcı bir cevabın hafta sonumu kurtarmasını umuyorum.

Görünüşe göre sorunlarım iki farklı sorundan kaynaklandı.

Sorun # 1 SSHFP, arama yollarının kullanılmasını desteklemiyor. Eğer /etc/resolv.conf dosyasına "domain example.com" eklerseniz, ssh myhost'ın SSHFP ile çalışmasını beklersiniz, çünkü normal ssh adı myhost.example.com olarak doğru şekilde çözecektir. Görünüşe göre OpenBSD geliştiricileri, 2 yıl önce bir yama yayınlandığından ancak hiçbir zaman uygulanmadığından sorunun farkındalar. Bunun yerine bir ssh_config hack önerildi, ancak bu da çalışmıyor gibi görünüyor. İlk sorunun çözümü FQDN'nin her zaman SSHFP ile kullanılması gerektiğidir.

Sayı # 2 Önceki sorunu çözmek için FQDN'leri kullanarak, OpenSSH istemcisinin OpenSSH_6.1 olan geçerli sürümünü kullanırsam her şey çalışır. FreeBSD sistemimdeki OpenSSH_5.8p2 istemcisi, yeni bir OpenSSH_6.1 sunucusu için SSHFP kayıtlarını bulabilir, ancak DNS'den aldığı parmak izini sunucudan aldığı parmak iziyle eşleştiremez. OS X 10.8.2 makinemdeki OpenSSH_5.9p1 istemcisi, istemcinin hiçbir zaman FreeBSD makinesinden daha yeni bir sürümü olmamasına rağmen, yeni bir OpenSSH_6.1 sunucusu için SSHFP kayıtlarını bile alamıyor. Açıkçası, var olmayan SSHFP kayıtlarını OpenSSH sunucusu tarafından döndürülen parmak izi ile eşleştiremiyor. Son olarak, FreeBSD kutusundaki ssh-keygen, OpenSSH_6.1 istemcilerine göre kötü SSHFP kayıtları üretir. t Sunucu tarafından döndürülen parmak iziyle eşleşir. Çözüm, SSHFP'nin çalışması için hem OpenSSH istemcisinin hem de sunucunun geçerli sürümünü çalıştırmanız gerektiği anlaşılıyor. İstemcinin veya sunucunun eski bir sürümünü kullanmak sorun istiyor.

Son Düşünceler SSHFP'nin DNS ile kullanılması, karışık bir işletim sistemi ortamında kullanılmak için çok ileri ve her şeyin "sadece işe yaraması" nedeniyle OpenBSD olmayan işletim sistemlerinin, taşındığı zamana kadar eski olan OpenSSH taşınabilirini taşıması gerektiğinden. Belki 3-5 yıl içinde SSHFP, diğer işletim sistemlerine taşınan eski sürümlerin bile kararlı ve en son sürümle uyumlu olacak kadar kararlı olacaktır.

SSH'nin bağlandığı sunucunun ana bilgisayar adı, SSHFP kaydındaki ana bilgisayar adıyla tam olarak eşleşmelidir. Yani, yalnızca iki ana makine adının aynı IP adresine çözümlenmesi yeterli değildir. Bu nedenle, ssh wwwwww SSH yapılandırmanızda böyle olmadığı sürece, www.test.us için olan SSHFP'ler için çalışmaz:

Host www
    Hostname www.test.us

Deneyin ssh www.test.us.

DNS kayıtları oluşturduğunuz hizmetin ortak anahtarının dosya adını sağlamanız gerekir. Aksi takdirde .ssh / *. Pub'dan kişisel ortak anahtar dosyalarınızı varsayılan yedek olarak kullanır.

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