web-dev-qa-db-ja.com

非対話型のgitクローン（ssh指紋プロンプト）

非インタラクティブな方法でリポジトリを複製したい。クローンを作成するとき、gitはホストのフィンガープリントの確認を求めます。

The authenticity of Host 'bitbucket.org (207.223.240.182)' can't be established.
RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? no

この質問がポップアップするたびに「はい」を強制するにはどうすればよいですか？ yes yes | git clone ...を使用してみましたが、機能しません。

編集：これが解決策です： known_hostsに新しいホストを自動的に追加できますか？ （ssh-keyscanで全体をknown_hostsに追加します）。

sshgit
143
qwe

「StrictHostKeyChecking no」オプションも「ssh-keyscan」オプションも安全ではありません。 sshを使い続ける場合にMiTM攻撃を回避するために、ある時点で手動の指紋検証が必要です。

実際には、2つのオプションがあります。

Gitの代わりにhttpsプロトコルを使用する

Sshが関与していないため、代わりにhttpsが使用されるため、フィンガープリントは要求されません。セキュリティの観点からは、OSのルート証明書のインストールを信頼しています。ミニマリストのイメージまたはDockerを使用している場合は、ca-certificatesパッケージをインストールする必要がある場合があります。

本当にgit + sshプロトコルが必要な場合

本当に実行時にキーを追加する必要がありますか？これは指紋をチェックしなかったため安全ではなく、MiTM攻撃にさらされたままになっています。これは単なる理論的なものではなく、機能することが証明されています。

スクリプトを実行する前に、（ローカルマシンの）githubからキーを取得します。

ssh-keyscan github.com >> githubKey

フィンガープリントを生成します。

ssh-keygen -lf githubKey

そして、それを手動でリストされたものと比較します このページ （ok、そこでは、https証明書とOpenSSLを信頼して元のgithub Webサイトを提供しますが、それでも公開鍵を盲目的に受け入れるよりははるかに優れています。

次に、スクリプトに追加してハードコードします。

echo '<copy paste the content of 'cat githubKey' on your machine>'  >> ~/.ssh/known_hosts

git cloneの前。

GitHub公開鍵は、侵害された（または十分に安全でない）と信じる場合にのみ変更されます。これが当てはまる場合、あなたwantとにかくスクリプトが失敗します。

120
autra

それは最善の解決策ではないと思いますが、それは私にとっての解決策でした。

回答：

known_hostsコマンドを使用してssh-keyscanファイルにドメイン名を追加すると、問題が解決しました：

ssh-keyscan <enter_domainname_e.g._github.com> >> ~/.ssh/known_hosts

115
kroe

~/.ssh/known_hostsファイルをバックアップして空にし、手動でSSH接続を実行し、IPアドレスとフィンガープリントmv ~/.ssh/known_hosts ~/bitbucket_hostsを確認してから、~/bitbucket_hostsの内容を使用することをお勧めします。既知のフィンガープリントをknown_hostsファイルに自動的に追加するスクリプト（元の~/.ssh/known_hostsを復元することを忘れないでください）。

この手順は（すべてのマシンで）1回だけ実行する必要があり、フィンガープリントを取得したら、それを自動化スクリプトに組み込むことができます。

9
Steven Soroka

あなたがそのようなプロセスを自動化したいことは確かに理解していますが、そうすることは賢明ではありません。安全なプロトコルを使用しているときにSSHと関連するネットワークサブコンポーネントが原因である理由は、システムの公開鍵が不明であることを人間に警告するためです。これは意図的なものです。ユーザーは、ホストが予期しているシステムに明示的に通知する必要があります。提示されたすべての公開鍵を自動的に受け入れたくない場合、またはSSHまたはTLS/SSLのセキュリティの一部が侵害される可能性があります。 1つの例としては、プロキシソフトウェアが期待するホストの代わりに独自のキーを提示する場合など、中間者攻撃によるものがあります。

注意して続行してください。

ネットワーク全体のコードのソースを心配する必要がない場合は、クローン作成時にgit：//プロトコルを明示的かつ排他的に使用する必要があります。これは、認証なしで平文です。

7
Jeff Stice-Hall

.ssh/known_hostsにキーを追加することは、正しいことのようです。

タスクを自動化するときは、キーが既に含まれておらず、各clone/pullタスクに追加されていないことを確認する必要があります。

このスニペットは、まだ見つからない場合にのみフィンガープリントを追加します。

if [ ! -n "$(grep "^bitbucket.org " ~/.ssh/known_hosts)" ]; then ssh-keyscan bitbucket.org >> ~/.ssh/known_hosts 2>/dev/null; fi
7
udondan

ジェフ・ホールが言ったように、検出されない中間者攻撃を許すので、そうすることは危険です。ただし、 StrictHostKeyChecking noオプション sshでホストキーのチェックを無効にします。ただし、私があなただった場合、そのオプションには細心の注意を払っています。

6
Wren T.