web-dev-qa-db-ja.com

Rsyncプロンプトをバイパスする「接続を続行してもよろしいですか？」

この質問をバイパスする方法、またはこれに自動応答するフラグを追加する方法を教えてください。

スクリプトを作成しようとしていますが、プロンプトが表示されたときにスクリプトでこれに答える方法がないため、この質問はrsyncのプロセスを停止し続けます。

linuxrsync
22
user1480718

設定ファイルまたは-oを介して、StrictHostKeyCheckingオプションをnoに設定します。

eのrsyncオプションを使用して、オプションをsshに渡します。

-e "ssh -o StrictHostKeyChecking=no"
36
Igor Chubin

だから、私はうまくいく安全でない答えをたくさん見つけていました-しかし、より良い方法はそれほど多くの仕事ではないので、rsyncのようなSSH関連のことを行う安全性の低い方法をアドバイスする投稿を探していました。私は、以下に示すようにgitリポジトリのクローンを作成するという未知のホストの手動操作をバイパスするありふれた方法を探していましたが、前述のrsyncやその他のテクノロジーで機能します。

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の問題であり、これはgit overSSHおよび一般的な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ファイルに追加します。これで既知のホストとして識別されるため、あなたが若い頃は上記のプロンプトは表示されません。

私に固執してくれてありがとう、ここに行きます。 Bitbucket RSAキーを追加して、CIワークフローの一部として非対話型の方法でgitリポジトリと対話できるようにしますが、必要なことは何でもできます。

#!/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/unknown_hosts

上記のいずれも行わないでください。中間者攻撃で誰かがデータ転送を盗聴するのを回避する可能性を高める機会が与えられます。その機会を利用してください。違いは、所有しているRSAキーが真正なサーバーの1つであることを文字通り確認することです。これで、接続を信頼できるように、その情報を取得して比較する方法がわかりました。さまざまなコンピューターやネットワークからの比較を増やすと、通常、接続を信頼する能力が向上することを覚えておいてください。

2
BradChesney79