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が現在有効になっていないため、警告が表示されるはずです。追加の問題としてこれに取り組む前に、まず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から接続してみました。
これをトラブルシューティングするためのさらなる試みで、私は新しい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サーバーに焦点を当てます。どこを見ればよいかという提案がない限り、私はパケットキャプチャを取り、手掛かりを見つけるためにそれらを掘り下げることに行き詰まっていると思います。
さて、これが私のパケットキャプチャの結果です。 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に保存されているレコードが、接続されているsshサーバーから返されたキーのフィンガープリントと同じではないことが簡単にわかります。
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サーバーから返された公開鍵と一致しない理由について誰かが何か提案はありますか?
私は私の最後のオプションに取りかかっています。週末の前に誰かが私を正しい方向に向けない限り、土曜日は完全にOpenBSDベースのVMを使用して複製環境を作成することに費やします。 OpenBSDはOpenSSHを所有しているため、これはDNSを介したSSHFPが機能するための理想的な条件である必要があります。 OpenBSD OpenSSHクライアントにバインドを提供するOpenBSD OpenSSHサーバーが機能しない場合、SSHFPは実装どおりに機能しなくなり、OpenBSDフォーラムに移動して、バグレポートを提出する可能性があります。私はまだ明白な何かが欠けていること、そして役立つ回答が私の週末を救うことを望んでいます。
どうやら私の問題は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は、サーバーから返されたフィンガープリントと一致しないためMITM攻撃について不平を言うOpenSSH_6.1クライアントによると、不正なSSHFPレコードを生成します。 SSHFPを機能させるには、OpenSSHクライアントとサーバーの両方の現在のバージョンを実行する必要があるという解決策のようです。クライアントまたはサーバーのいずれかの古いバージョンを使用すると、問題が発生します。
最終的な考え DNSでSSHFPを使用することは、混合OS環境で使用するにはEdgeを切断するようであり、OpenBSD以外のOSはOpenSSHポータブルを移植する必要があるため、移植された時間。おそらく3〜5年以内に、SSHFPは十分に安定しているため、他のOSに移植された古いバージョンでも安定しており、最新バージョンと互換性があります。
SSHが接続しているサーバーのホスト名は、SSHFPレコードのホスト名と正確に一致する必要があります。つまり、2つのホスト名が同じIPアドレスに解決されるだけでは不十分です。したがって、wwwが次のようなSSH構成にない限り、ssh www
はwww.test.us.用のSSHFPに対しては機能しません。
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