高可用性クラスタの現在アクティブなヘッドに接続する必要があるスクリプトがあります。
クラスタ内の各ノードには固定ホスト名とIPアドレスがあります。
現在、ヘッドにも「仮想IP」があります。遷移またはフェイルオーバーが発生した場合、他のノードが「仮想 IP」として構成され、ヘッドの役割を開始します。
私のスクリプトは仮想IPを指すことができますか？sshクラスタが仮想IPを別のノードに移動するときにホストキーの不一致について文句を言いませんか？
答え1
はい、可能です。
sshd(8)（OpenSSHで）ファイル形式を指定しますknown_host（セクションではSSH_KNOWN_HOSTS FILE FORMAT）。
ホスト認証を実行するときに一致する行に正しいキーがある場合、認証は許可されます。
同じ名前または複数のホストキーを持つ複数行が許可されますが、お勧めできません。 これは、他のドメインのホスト名の短縮バージョンがファイルに含まれるときに必然的に発生します。これらのファイルには、競合する情報を含めることができます。どちらのファイルにも有効な情報が見つかった場合は、認証が許可されます。
したがって、両方のHAヘッダーのホストキーを~/.ssh/known_hostsORに追加するだけです/etc/ssh/ssh_known_hosts。
203.0.113.50 ssh-rsa AAAAB3NzaC1yc2…6Yh5sHpkyIZvXLB
203.0.113.50 ssh-rsa AAAAB3NzaC1yc2…R0RNVnMB6C4plFr
そしてssh苦情なしに両方に接続されます。
答え2
はい、最初の答えそうだね
ただし、バージョン8.5以降、OpenSSHクライアントではUpdateHostKeysデフォルトでssh_configオプションが有効になっており、このオプションが有効になっていると、クライアントは接続されているホストにないすべてのホストキーを自動的に削除するため、このソリューションは機能しなくなります。たとえば、クライアントの Known_hosts ファイル内の 2 つのホスト間にフローティングするサービス IP があり、各ホストには独自のホストキーがあります。
これを防ぐには、UpdateHostKeys noクライアント~/.ssh/configファイルに設定を指定して以前の動作を復元する必要があります。
答え3
これは有効な質問かもしれませんが、ほとんどの場合これはXYの問題です。
まず、フローIPは高可用性ソリューションとしては適していません。より良いソリューションを実装することは非現実的な場合がありますが、これらのケースはまれです（たとえば、デフォルトゲートウェイアドレス）。
クラスタの主な目的がSSHサーバーとして機能していない場合は、BAUトラフィックと同じ方法でルーティング管理トラフィック（SSH）は必要ありません。クラスタノードの1つに障害が発生した場合1）これをどのように確認し、2）問題を解決しますか？各ノードに接続できる必要があります。どのノードがクラスタリーダーであるかを知る必要があります（別々のデバイスでNATを使用している場合は、各ノードまたはコントローラのクラスタデーモンからそれを取得する必要があります）。
しかし、そのすべてを取り除いて...
SSH はホスト鍵の不一致について文句を言いません。
sshにこれを行わないように指示すると、そうではありません。 ssh_configのエントリを使用すると、仮想IPに対して特にこれを実行できます。スクリプトがパスワードで何か厄介なことをしない限り、セキュリティ上のexpect問題はありません。何か厄介なことをしている場合は、いつでも主な問題をホストして処理expectできます。expect
すべてのノードが同じホストキーを持つ場合はそうではありません。