解決策 1:
ssh -o StrictHostKeyChecking=no を使用できます known_hosts のチェックをオフにするには 一瞬。しかし、私はこれに反対することをお勧めします。ホスト キーが変更された理由を確認する必要があります。
別のオプションは、特定のエントリを ~/.ssh/config に追加することです 問題のホストに対して。これは、再起動するたびに新しいホスト キーを生成する特定のホストがあり、正当な理由で 1 日に数回再起動される場合に有効な方法です。
Host <your problematic host>
StrictHostKeyChecking no
解決策 2:
POSIX 環境で既知の hosts ファイルを完全に無視するには、GlobalKnownHostsFile を設定します。 と UserKnownHostsFile /dev/null へのオプション :
ssh -o GlobalKnownHostsFile=/dev/null -o UserKnownHostsFile=/dev/null [email protected]
StrictHostKeyChecking=no の設定 オプションで接続できますが、SSH まだ警告が表示されます :
ssh -o StrictHostKeyChecking=no [email protected]
他の人が指摘したように、根本的な問題に対処する方がおそらく良いでしょう。たとえば、ホストを検証するために SSH 証明書認証を検討できます。
解決策 3:
サーバーを再インストールしたために ID が変更された場合は、指定された行 155 を /Users/alexus/.ssh/known_hosts から削除するだけです。
異なるプライベート ネットワークを切り替える場合は、ホスト名に応じて ssh クライアントもキーを保存するため、代わりにホスト名を使用して接続する必要があります。このようなものを /etc/hosts に追加します :
10.52.11.171 server1
10.52.11.171 server2
ssh server1 を使用します サブネット 1 および ssh server2 に接続されている場合 サブネット 2 に接続されている場合。このようにして、両方のサーバーが異なるホストキーを持つことができます。
解決策 4:
-o StrictHostKeyChecking=no ホストが known_hosts ファイルにまだ存在しない場合にのみ機能します。
おそらく vm のクローン作成が原因でホスト キーが変更されることが予想される場合は、次のような種類のホストを強制的に無視する方がクリーン (警告なし) だと思います:
# Handle possible SSH key changes
host_key=$(ssh-keyscan -t rsa ${host_ip})
grep "${host_key}" ~/.ssh/known_hosts >/dev/null || {
ssh-keygen -R ${host_ip}
echo ${host_key} >> ~/.ssh/known_hosts
}
# connect as normal way
ssh [email protected]${host_ip} "hostname"
解決策 5:
一部の人々は、これは正しくないと言いますが、これを行うべきではありませんが、いくつかの組み込みデバイスを何度もテストするためにもこれが必要です。StrictHostKeyChecking=no を無効にする必要があります 、これは正しいですが、既知のホスト ファイルを /dev/null にリセットします .自動ログインと ps の例
sshpass -p pass ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null [email protected] 'ps ax'