known_hostsを置き換えるためにDNSでSSHフィンガープリントを構成すると失敗する

SSHFPレコードは、sshサーバーで次のように生成され、バインドでゾーンに追加されました。

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

必要なレコードは、次のようにDNSを介してsshクライアントから取得できます。

$ 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サーバーはOpenSSH_5.8p2_hpn13v11を備えたFreeBSD 9.1であり、BIND 9.8.3-P4を使用してDNSもホストしています。OpenSSH_5.9p1でOS X 10.8.2から、OpenSSH_6.1p1でArch Linux 3.6.10-1-ARCHから接続してみました。

更新

これをトラブルシューティングするためのさらなる試みとして、OpenSSH_6.1がsshサーバーとして組み込まれている新しいOpenBSD 5.2 VMを立ち上げました。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ベースのVMを使用して複製環境を作成することに費やします。OpenBSDはOpenSSHを所有しているため、これはDNSを介したSSHFPが機能するための理想的な条件である必要があります。OpenBSD OpenSSHクライアントにバインドを提供するOpenBSD OpenSSHサーバーが機能しない場合、SSHFPは実装どおりに機能せず、OpenBSDフォーラムに移動し、バグレポートを提出する可能性があります。私はまだ明白な何かが欠けていること、そして役立つ回答が私の週末を救うことを望んでいます。

ssh dns bind

— マイケル安本
ソース

明示的に接続するように接続しようとしましたwww.test.usか？

— Ulrich Dangel 2013年

はい。すみません、私はすべてのバリエーションを試したことを述べるべきでした：ssh www; ssh www.test.us; ssh www.test.us .; それらはすべて同じ応答になります。

— Michael Yasumoto 2013年

Wireshark / tcpdumpから、DNSサーバーから何が照会され、どの応答が送信されているかを確認すると興味深いでしょう。正確なクエリと応答を知ることは、問題を見つけるのに役立ちます。

— Gert van den Berg

ガート、私はこのコメントボックスに応答を収めることができなかったため、上記の更新で応答しました。

— Michael Yasumoto 2013年

IPアドレスで直接接続してみてください。私には、ssh到達しようとしているホスト名と一致しないDNSレコードによって混乱しているようです。

— peterph 2013年

どうやら私の問題は2つの異なる問題が原因で発生しました。

問題＃1 SSHFPは検索パスの使用をサポートしていません。したがって、「domain example.com」を/etc/resolv.confに追加すると、通常のsshが名前をmyhost.example.comに正しく解決するため、ssh myhostがSSHFPで機能することが期待されます。どうやらOpenBSDの開発者たちは、パッチが2年前に発行されて以来、この問題を認識していますが、適用されませんでした。代わりにssh_configハックが提案されましたが、それも機能していないようです。したがって、最初の問題の解決策は、FQDNを常にSSHFPで使用する必要があることです。

第2号 前の問題を解決するためにFQDNを使用して、OpenSSH_6.1であるOpenSSHクライアントの現在のバージョンを使用している場合、すべてが機能します。私のFreeBSDシステムのOpenSSH_5.8p2クライアントは、新しいOpenSSH_6.1サーバーのSSHFPレコードを見つけることができますが、DNSから受け取ったフィンガープリントとサーバーから受け取ったフィンガープリントを照合することができません。私のOS X 10.8.2マシンのOpenSSH_5.9p1クライアントは、FreeBSDマシンよりもクライアントのバージョンが決してないにもかかわらず、新しいOpenSSH_6.1サーバーのSSHFPレコードを取得することさえできません。明らかに、存在しないSSHFPレコードをOpenSSHサーバーから返されたフィンガープリントと照合することはできません。最後に、FreeBSDボックスのssh-keygenは、MITS攻撃について不平を言うOpenSSH_6.1クライアントによると、不正なSSHFPレコードを生成します。tサーバーから返された指紋と一致します。SSHFPを機能させるには、OpenSSHクライアントとサーバーの両方の現在のバージョンを実行する必要があるという解決策のようです。クライアントまたはサーバーのいずれかの古いバージョンを使用すると、問題が発生します。

最終的な考え DNSでSSHFPを使用することは明らかに最先端であり、混合OS環境で使用するには「OpenSSH Portable 」を移植する必要があります。おそらく3〜5年で、SSHFPは十分に安定しているため、他のOSに移植された古いバージョンでも安定しており、最新バージョンと互換性があります。

— マイケル安本
ソース

OS X（10.9）にOpenSSHの6.Xバージョンが含まれるようになったにもかかわらず、GitHubによって報告されたOS Xの実装が壊れているため、SSHFPはまだ機能しません。MacPortsのクライアントなど、別のOpenSSHクライアントへの置き換えが現在唯一のソリューションです。

— Michael Yasumoto 14

SSHが接続しているサーバーのホスト名は、SSHFPレコードのホスト名と正確に一致する必要があります。つまり、2つのホスト名が同じIPアドレスに解決されるだけでは不十分です。したがって、ssh wwwwwwが次のようなSSH構成にない限り、www.test.us。用のSSHFPでは機能しません。

Host www
    Hostname www.test.us

試してくださいssh www.test.us。

— htoip
ソース

申し訳ありませんが、上記の私の投稿全体を読んでいないようです。完全修飾ドメイン名（FQDN）を使用してテストしましたが、これは問題ではありませんでした。

— Michael Yasumoto 14

DNSレコードを作成するサービスの公開鍵のファイル名を指定する必要があります。それ以外の場合は、.ssh / *。pubからの個人の公開鍵ファイルをデフォルトのフォールバックとして使用します。

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

— オオカミ
ソース