VIPを使用したSSHホストキー検証の問題

VIPには2つの本番サーバーがあり、一度に1つだけ使用されます。次に例を示します。

myservice.mycompany.ukは通常、server1をポイントします。server1に障害が発生した場合、server2をポイントするように変更されます。

SFTP経由でmyservice.mycompany.ukにファイルを送信する必要のある他のサーバーがいくつかあり、server2にフェイルオーバーする場合、サーバーに対して完全に透過的である必要があります。

問題は、server1とserver2の両方にキーがインストールされている間、server2のホストキーがserver1のホストキーと異なるため、他のサーバーでホストキーの検証問題が発生することです。これにより、セキュリティエラーが発生し（厳密なチェックがオンになっているため）、動作させるには、known_hostsから行を削除する必要があります。

IT担当者は、known_hostsに2つのエントリを作成できることを示唆しています。1つはserver1のキー、もう1つはserver2のキーで、どちらもホストmyservice.mycompany.ukです。

それはうまくいくでしょうか？これは、Windowsのputty / psftpでどのように実行できますか？ホストキーはレジストリに保存されているため、重複した名前は許可されていません。より良い方法はありますか？たとえば、サーバーに同じホストキーを強制することはできますか？

ssh cluster sftp

— ポール・クリーシー
ソース

回答:

クライアントにとって簡単にするために、両方のマシンで同じホストキーを使用します。キーの1つ（現在使用中のサーバーの1つ）を2番目のマシンにコピーするだけです。キーはにあり/etc/ssh/ssh_host_*ます。

別のオプションは、クライアントのホストキーチェックを無効にすることです。これはssh_config、使用するように調整することで実行できます。

Host myservice.mycompany.uk
    StrictHostKeyChecking

— phaphink
ソース

ホストキーチェックをオフにすると、SSHを使用してこれらのファイルを転送するポイントが損なわれるため、ホストキーの複製がおそらく最善の解決策です。

— ジェームズイェール

ホストキーチェックをオフにしても、通信が適切に暗号化されていないというわけではありません。これがSSHの主要なポイントです。そうは言っても、私が言ったように、私は最初の解決策を自分で支持します。

— ℝaphink

ソリューションのクライアントバージョン（異なるサーバーキーを使用）では、追加する必要があります。追加しない場合 UserKnownHostsFile=/dev/null、最初のキーは既知のホストに入力され、2番目のキーは「中間者」警告につながります。

— Nils

@Nilsこれは必要ありません。設定StrictHostKeyChecking yesにより、システムの既知のホストファイルが優先され、UserKnownHostsファイルは無視されます。そのため、UserKnownHostsを変更することは何の意味もありません。

— マイケル・ローマン、2011

わかりました-これをさらに明確にする必要があります。2つの異なるサーバーキーがある場合について話します。そこでStrictHostKeyChecking no、UserKnownHostsFile/ dev / null を指定し、さらに設定する必要があります。その場合、すべてのホストキーが受け入れられます（もちろん、このセキュリティレベルは役に立たなくなります）。

— ニルス2011

私はこれをこの方法でアーカイブしました。ユーザーrootは午後23:00にLinuxクラスターの論理IPアドレスに接続する1つのスクリプトを実行します。そのため、IPアドレスのフェイルオーバーの場合は私のsshフィンガープリントが変更されます

echo "StrictHostKeyChecking no" >> /root/.ssh/config 
echo "UserKnownHostsFile /dev/null" >> /root/.ssh/config

このように、設定はroot専用です

— c4f4t0r
ソース