これを試してください:
ssh-keyscan -t rsa [ip_address]
出力を取得して、.ssh/known_hosts に貼り付けます。known_hosts をハッシュする場合は、次のようにします。
ssh-keygen -H
編集: Heres は、1 つのコマンド ソリューションです。ホスト名と IP アドレスを使用し、両方をハッシュします。
ssh-keyscan -Ht rsa [hostname],[IP address] >> known_hosts
kschurig による回答は機能しますが、必ずしも最も安全であるとは限りません。複数のURI、つまりホスト名とIPアドレスでサーバーを識別できるようにするために、さらに一歩進んだことでボーナスポイントが得られます。つまり、コンマ区切りのリストを拡張することで、そのホストの有効な URI を追加し続けることができます。
ただし、以下に示すように、不明なホストによる git リポジトリのクローン作成の手動操作を回避するありふれた方法を探していました。これは、何が起こっているのか、および SSH 関連のスクリプト作成のこの部分を回避する方法を説明するのに役立つはずです:
[email protected]:~$ git clone [email protected]:viperks/viperks-api.git
Cloning into 'viperks-api'...
The authenticity of host 'bitbucket.org (104.192.143.3)' 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)?
RSA キーのフィンガープリントに注意してください...
つまり、これは SSH のことです。これは、SSH を介した git と、一般的な SSH 関連のことだけで機能します...
[email protected]:~$ nmap bitbucket.org --script ssh-hostkey
Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-05 10:21 EDT
Nmap scan report for bitbucket.org (104.192.143.3)
Host is up (0.032s latency).
Other addresses for bitbucket.org (not scanned): 104.192.143.2 104.192.143.1 2401:1d80:1010::150
Not shown: 997 filtered ports
PORT STATE SERVICE
22/tcp open ssh
| ssh-hostkey:
| 1024 35:ee:d7:b8:ef:d7:79:e2:c6:43:9e:ab:40:6f:50:74 (DSA)
|_ 2048 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40 (RSA)
80/tcp open http
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 42.42 seconds
まず、日常のドライバーに nmap をインストールします。 nmap は、開いているポートの検出や、SSH フィンガープリントの手動検証など、特定の作業に非常に役立ちます。しかし、私たちがやっていることに戻りましょう。
良い。私はチェックした複数の場所とマシンで侵害されているか、またはすべてがハンキードーリーであるというよりもっともらしい説明が起こっている.
その「指紋」は、複数の文字列が同じ指紋に解決されるリスクを冒して、人間の便宜のために一方向アルゴリズムで短縮された単なる文字列です。これは衝突と呼ばれます。
いずれにしても、以下のコンテキストで確認できる元の文字列に戻ります。
[email protected]:~$ ssh-keyscan bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
no hostkey alg
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-129
bitbucket.org ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-123
no hostkey alg
そのため、事前に、元のホストに身分証明書の形式を要求する方法があります.
この時点で、手動でも自動でも脆弱です。文字列が一致し、フィンガープリントを作成するベース データがあり、将来的にそのベース データを要求する (衝突を防ぐ) ことができます。
ホストの真正性について尋ねるのを防ぐ方法でその文字列を使用するには...
この場合の known_hosts ファイルは、プレーンテキスト エントリを使用しません。ハッシュ化されたエントリは、見ればわかります。これらは、xyz.com や 123.45.67.89 ではなく、ランダムな文字を含むハッシュのように見えます。
[email protected]:~$ ssh-keyscan -t rsa -H bitbucket.org
# bitbucket.org SSH-2.0-conker_1.0.257-ce87fba app-128
|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==
最初のコメント行が腹立たしく表示されますが、">" または ">>" 規則による単純なリダイレクトでそれを取り除くことができます。
「ホスト」と信頼を識別するために使用する汚染されていないデータを取得するために最善を尽くしたので、この識別情報を ~/.ssh ディレクトリの known_hosts ファイルに追加します。これで既知のホストとして識別されるため、上記のプロンプトは表示されなくなります.
付き合ってくれてありがとう、どうぞ。 CI ワークフローの一部として非対話的な方法で Git リポジトリと対話できるように、bitbucket RSA キーを追加していますが、やりたいことは何でもできます。
#!/bin/bash
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old && echo "|1|yr6p7i8doyLhDtrrnWDk7m9QVXk=|LuKNg9gypeDhfRo/AvLTAlxnyQw= ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==" >> ~/.ssh/known_hosts
だから、それはあなたが今日の処女を維持する方法です.自分の時間に同様の指示に従って、github で同じことを行うことができます。
何のチェックもせずにプログラムでやみくもにキーを追加するように指示するスタック オーバーフローの投稿をたくさん見ました。さまざまなネットワーク上のさまざまなマシンからキーをチェックすればするほど、ホストが言うとおりのものであるという信頼を得ることができます。これは、このセキュリティ層から期待できる最高のものです.
間違ったssh -oStrictHostKeyChecking=ホスト名なし [コマンド]
間違ったssh-keyscan -t rsa -H ホスト名>> ~/.ssh/known_hosts
上記のいずれも行わないでください。中間者攻撃を介して誰かがデータ転送を傍受するのを回避する機会を増やす機会が与えられます。その機会を利用してください。違いは、あなたが持っている RSA キーが本物のサーバーのものであることを文字通り検証することです。これで、その情報を取得してそれらを比較する方法がわかったので、接続を信頼できます。通常、異なるコンピューターやネットワークからの比較を行うことで、接続を信頼する能力が向上することを覚えておいてください。