SSHのknown_hostsにホストキーを追加しないでください

111

SSH経由でホストに接続したいのですが、ホスト名をに追加したくありません~/.ssh/known_hosts。

どうやってやるの？

ssh hosts

— アルバート
ソース

99

-o "UserKnownHostsFile /dev/null"

動作するはずです。

— アルバート
ソース

3

意図したとおりに機能しますが、常に報告されます：「警告：既知のホストのリストに「hostname、ip」（RSA）を永続的に追加しました。」2>＆1 | grep -v "^Warning: Permanently added"

— ギヨーム・ボドロー

3

-o "LogLevel ERROR"を追加すると、警告メッセージが表示されなくなります。

— ジョン

1

注：「警告：既知のホストのリストに 'hostname、ip'（RSA）を永続的に追加しました」というメッセージを抑制する要求。メンテナーに報告されたbugzilla.mindrot.org/show_bug.cgi?id=2413

— Ben Creasy

2

に配管するgrepと、stdoutとstderrがマージされます。終了ステータスも変更できます。使用している場合bash、メッセージを取り除くために、プロセスの置換を使用する方がよいでしょう：ssh 2> >( egrep >&2 -v '^Warning: Permanently added') -o "UserKnownHostsFile /dev/null" [...]。パイプを回避するため、終了ステータス処理の対応する変更が回避されます。

— アレックスO

1

他の、無関係の警告を非表示にするには、潜在的にそうしないと、セキュリティ上の欠陥を導入している、これらのコメントの他の方法のいずれかを使用することをお勧めします@ジョン

— ジョン・ベントレー

97

クラウドサーバー（AWS EC2、Rackspace CloudServersなど）で作業しているため、またはVagrantで新しいイメージを常にプロビジョニングしているためにこの動作が必要な場合は、bashエイリアスまたはその他のオプションを追加する代わりにコマンドライン。

次のようなものを追加することを検討してください。

Host *.mydomain.com 
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  User foo
  LogLevel QUIET

安全のために、ホストの正規表現と同じように厳密に使用してください。
LogLevelをQUIETに設定すると、Guillaumeが言及した警告が表示されなくなります

— クラーク
ソース

本当にStrictHostKeyCheckingを完全に無効にしないようにしてください。そのため、cclarkの答えは、クラウドサーバーでの作業にとって大きな妥協です。

— アレックスRecarey

Vagrantに対してShipit（JavaScript展開ツール）を使用していたので、これは非常に役立つことがわかりました。ShipitがSSHに渡すパラメーターを簡単に取得できなかったため、ツールを回避して、自分が何をしたか、覚えてほしくないかを伝えることができました。

— ジョンマンシュ

1

LogLevelは私が探していたものです。スクリプトを実行するときに、会社が設定した通知を表示しないという追加の利点があります！（私は現在ログレベルエラーで実行しています）

— アン

どのファイルにこれを追加しますか？

— ウィムデブラウウェ

これはSSH構成ファイルです。LinuxまたはmacOSでは、ファイルは通常、ホームディレクトリ内の.sshというディレクトリにあり、configという名前になります。〜/ .ssh / config

— cclark

8

ホストキーをknown_hostsに追加します（私の経験では、これらのサービスを実行している人は、少なくとも同じホスト名を提供するマシン間でホストキーの一貫性を保つのに十分な賢さです）。 LogLevel ERRORを使用してログを記録すると、セキュリティを犠牲にすることなく最高のエクスペリエンスが得られます。（OK、CheckHostIPを使用しない場合、DNSを信頼する必要があります。これは、広範にわたるDNSSECまたは類似のもののない巨大なギャップホールです。

読み取り専用のknown_hostsファイルを使用しているため、何かしなければならないか、known_hostsにエントリを追加できないという警告が何度も表示されます。

私が使用するもの：

Host github.com *.github.com
StrictHostKeyChecking yes
CheckHostIP no
LogLevel ERROR

これらのサービスがHTTPSを介してSSHホストキーをWebサイトに公開するようにしたいので、最初に接続しなくてもMITM攻撃にさらされる可能性なく明示的にコピーできます。

— カイル・ローズ
ソース

7

単一のsshセッションでは、これを使用します

ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null user@host

— 泉龍
ソース

4

これにより、5年前の質問に対する受け入れられた回答に新しいものは何も追加されません。

— JakeGould

5

私は提案します

LogLevel ERROR

以上

LogLevel QUIET

そのため、「ホスト名を解決できませんでした」などのエラーが引き続き表示されます

— キロフォース
ソース

私のSSH接続を信頼できるはずです。リスクについて黙らせるだけではありません。

— シルヴァングル

3

本当に依存します。毎週取り壊されて再構築される開発環境があり、Aレコードは同じままですが、構築されるたびにホストキーが生成されます。Aレコードは環境名に基づいてデータベースで定義されているだけで、ホスト名を永続化することはできません。また、環境名はいつでも破棄または新規作成できるため、上記の回避策は本当に役立ちます。

— アレックスベリー

2

無効にしてみましたStrictHostKeyCheckingか？あなたがそれを行うことができます-oオプションまたは構成ファイルに~/.ssh/config。

— ニーブ
ソース

私はすでにそれを使用しています。ただし、異なる効果があります。ホストキーチェックの厳密性が低下します。つまり、ホストが不明な場合、そのオプションを無効にしてもホストは接続します。したがって、それでもホストを保存します。しかし、私は正しい解決策を見つけたと思います（私の答えを見てください）。

— アルバート

0

次の.ssh / configエントリが有用であることがわかりました（DHCPとDNSを使用したLAN）：

 CheckHostIP no

 Host *.*
 CheckHostIP yes

結果は、ローカルマシン名「zora」または「goron」は動的に割り当てられたIPアドレスに対してチェックしませんが、www.mycompany.comまたはnode42.planetlab.comはまだ静的IPを確認しています。

— シルヴァインウルグ
ソース