私はリモートrsyncセットアップをスクリプト化しています。スクリプトが最初に実行されたときに以下のメッセージが表示されないようにするには、リモートサーバーをローカルのknown_hostsファイルに追加する必要があります。
ホスト '[ホスト名]([IPアドレス])'の信頼性を確立できません。 RSAキーフィンガープリントは[キーフィンガープリント]です。接続を続行してもよろしいですか(はい/いいえ)?
として known_hostsに新しいホストを自動的に追加できますか? (新しいknown_hostsファイルを使用して)試しました:
ssh-keyscan -H [hostname],[ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [ip_address] >> ~/.ssh/known_hosts
ssh-keyscan -H [hostname] >> ~/.ssh/known_hosts
しかし、これは機能しません。常に指紋を受け入れるように求められます。
Sshにこれを追加させると、know_hostsファイルのキーハッシュが大きく異なります。
この問題をトラブルシューティングするには、他に何をすべきですか?
これを試して:
ssh-keyscan -t rsa [ip_address]
出力を取得し、.ssh/known_hostsに貼り付けます。次に、known_hostsをハッシュしたい場合は、次のようにします。
ssh-keygen -H
編集:ここに1つのコマンドソリューションがあります。ホスト名とIPアドレスを使用し、両方をハッシュします。
ssh-keyscan -Ht rsa [hostname],[IP address] >> known_hosts
Kschurigによる回答は機能しますが、必ずしも最も安全であるとは限りません。サーバーを複数のURI(ホスト名とIPアドレス)で識別できるようにするために、さらに1マイル進むとボーナスポイントを獲得できます。つまり、コンマ区切りのリストを拡張することで、そのホストの有効なURIを追加し続けることができます。
しかし、私は以下に示すようにgit repoのクローンを作成するという未知のホスト手動操作をバイパスする平凡な方法を探していましたが、これは何が起こっているのか、およびSSH関連のスクリプトの一部を回避する方法を説明するのに役立つはずです:
brad@computer:~$ 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関連のものだけで一般的に機能します...
brad@computer:~$ 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フィンガープリントを手動で検証するなど、特定の状況で非常に役立ちます。しかし、私たちがやっていることに戻ります。
良い。私はそれをチェックした複数の場所とマシンで妥協している-またはすべてがおかしいドーリーであるというよりもっともらしい説明は何が起こっているのかである。
その「指紋」は、複数の文字列が同じ指紋に解決されるリスクがあるという、人間の便宜のために一方向アルゴリズムで短縮された文字列です。起こります、それらは衝突と呼ばれます。
とにかく、以下のコンテキストで確認できる元の文字列に戻ります。
brad@computer:~$ 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ではなく、ランダムな文字を含むハッシュのように見えます。
brad@computer:~$ 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 = no hostname [コマンド]
違う ssh-keyscan -t rsa -Hホスト名>>〜/ .ssh/known_hosts
上記のいずれも行わないでください。中間者攻撃を介して誰かがデータ転送を盗聴するのを回避する機会を増やす機会が与えられます-その機会を利用してください。違いは、お持ちのRSAキーが正規のサーバーの1つであることを文字通り確認していることです。これで、その情報を取得してそれらを比較し、接続を信頼できるようになります。異なるコンピューターやネットワークからのより多くの比較は、通常、接続を信頼する能力を高めることを覚えておいてください。