web-dev-qa-db-ja.com

トンネリングに使用する場合、SSHはどの程度安全ですか？

シナリオ：SSH/SFTPを使用してクライアントAからクライアントBに接続したい。どちらのクライアントでもポートを開けません。この問題を解決するために、中継サーバーとして使用する安価なVPSを入手しました。

クライアントBで、次のようにリモートポート転送を使用してVPSに接続します。

ssh -4 -N -f -R 18822:localhost:22 <user>@<vps-ip>

VPSでは、次のように-g（グローバル）を使用してローカルポート転送を設定しました。

ssh -g -f -N -L 0.0.0.0:18888:localhost:18822 <user>@localhost

そうすれば、クライアントAから<vps-ip>:18888でクライアントBに直接接続できます。よく働く。

今私の質問は、これはどのくらい安全ですか？私の知る限り、SSH/SFTP接続は完全に暗号化されていますが、途中でVPSを使用することで安全性が低下する可能性はありますか？

次の2つのケースを想定します。

ケースA：VPS自体は変更されませんが、トラフィックとファイルは完全に監視されます。

ケースB：VPSは完全に危険にさらされており、ファイルシステムの内容が変更される可能性があります。

クライアントAからクライアントBにSFTP経由でファイルを送信すると、VPSをホストしている会社がそのファイルを「傍受」して、ファイルの（暗号化されていない）コンテンツを読み取ることができますか？

sshnetworkingsecurityencryptionssh-tunneling
6
confetti

あなたがしたこと

three sshコマンドを使用しました：

  1. [〜＃〜] b [〜＃〜] コンソールの中で、次のようにしました：

    ssh -4 -N -f -R 18822:localhost:22 <user>@<vps>

    ローカルホスト（B）ポート22に接続されたポート18822、 remote ポートvps:18822を開くためのコマンドsshd（サーバー）。

  2. vps コンソールで：

    ssh -g -f -N -L 0.0.0.0:18888:localhost:18822 <user>@localhost

    内部に接続する（vps）の external （18888）ポートとして使用可能なポート0.0.0.0を開くコマンドssh（クライアント）ポート18822。

    これにより、インターネット表示ポートvps:18888が開き、トラフィックが18822にリダイレクトされ、次にB:22にリダイレクトされます。

  3. [〜＃〜] a [〜＃〜] コンソール（およびAが参加する only 接続）で：

    クライアント [〜＃〜] a [〜＃〜] からクライアント [〜＃〜] b [〜＃〜] に直接接続vps:18888。

重要なのは、この最後の接続です。
SSHセキュリティ全体は、 authentication の [〜＃〜] a [〜＃〜] から [〜＃〜] b [〜＃〜] 。

その意味

SSHプロトコル

SSHは、安全でないネットワーク上で安全なチャネルを提供します

エンドツーエンドの暗号化 を使用する

エンドツーエンド暗号化（E2EE）は、通信するユーザーだけがメッセージを読み取ることができる通信システムです。原理的には、通信プロバイダー、インターネットプロバイダー、さらには通信サービスのプロバイダーを含む潜在的な盗聴者が、会話の復号化に必要な暗号化キーにアクセスできないようにします。

エンドツーエンドの暗号化は概念です。 SSHはプロトコルです。 SSHは、エンドツーエンドの暗号化を実装しています。したがって、https、または暗号化された他の任意の数のプロトコルを使用できます。

/プロトコルが強力である場合、および実装が正しい場合、暗号化キーを知っているのは2つの authenticated （end）パーティ。

鍵を知らず、プロトコルのセキュリティを破ることができないため、他の当事者は通信の内容から除外されます。

If 、あなたが説明したように：クライアントAからクライアントBに直接認証し、システムBに直接認証します。 then 、クライアントAとクライアントBだけがキーを持っています。他にない。

Q1

ケースA：VPS自体は変更されませんが、トラフィックとファイルは完全に監視されます。

通信（日、時刻、エンドIPなど）が行われていること、およびある程度のトラフィック（キロバイト、メガバイト）を監視できたが、通信内容の実際の内容は監視できなかったという事実のみ。

Q2

ケースB：VPSは完全に危険にさらされており、ファイルシステムの内容が変更される可能性があります。

通信が他のサイト/場所を経由して再ルーティングされても、キーを知っている2つの当事者はAとBのみです。つまり、 If 通信開始時の認証はAとBの間でした。

オプションで、Aが接続しているIPの有効性を確認してから、公開鍵認証を使用します（ once AとBだけが知っている秘密公開鍵のペアのみを使用）、完了。

使用する公開鍵がシステムBに安全に伝送されることを確認することを理解してください。同じチャネルを信頼して鍵を伝送し、その後暗号化を伝送することはできません。 プロトコルを破壊する可能性のある中間者攻撃 があります。

Q3

クライアントAからクライアントBにSFTP経由でファイルを送信すると、VPSをホストしている会社がそのファイルを「傍受」して、ファイルの（暗号化されていない）コンテンツを読み取ることができますか？

いいえ、公開鍵が両端に安全に配置されていれば、その可能性はほとんどありません。

公開鍵のあるディスクを持って反対側に歩いてインストールしてください。もう心配する必要はありません。

コメント

あなたのコメントから：

Q1

つまり、基本的に私の設定のVPSはポートを転送するだけであり、実際のSSH接続やクライアントAからBへの認証に関与していません。

やや。はい、VPS /は認証に関与しないでください。しかし、それは「中間」です。つまり、一方の側からパケットを受信し、それらが（正しく動作している場合）反対側に配信します。しかし、代替案があります。VPS（または中間者）は嘘および 「中間者攻撃」を実行することを選択できます） 。それは、クライアントAのふりをしてクライアントBであり、クライアントBのふりをしてクライアントAである可能性があります。それは「中間者」へのコミュニケーションのすべてを明らかにするでしょう。それが、私が上記の単語を強調する必要がある理由です。

私 それも言うべきです ：

...公開鍵方式を使用して認証されたSSH接続に対してMITMを実装するツールはありません...

パスワードベースの認証は、 not public-key methodです。

パスワードで認証すると、中間者攻撃を受ける可能性があります。他にもいくつかの代替案がありますが、この投稿の範囲外です。

基本的に、 ssh-keygenを使用してキーのペアを生成 （サイドAで想定）、および（正しいセキュリティのため）ディスク内のパブリック部分をサイドBに運び、Authorized-にインストールしますキーファイル。 not ネットワークを使用して公開キーをインストールします。つまり、実際に実行する場合を除き、ネットワーク経由で ssh-copy-idを使用しない を使用します do 自分が何をしているかを正確に把握しており、サイドBのIDを確認できます。これを安全に行うには、専門家である必要があります。

Q2

しかし、公開鍵については、公開ではないでしょうか。

  • はい、公開しています。
    ええ、そうです、パブリックプライベートペアを生成したエンティティは、パブリックパーツをだれにも（誰でも）公開でき、秘密を失うことはありません。誰かがその公開鍵で暗号化した場合、一致する（そして秘密の）秘密鍵でメッセージを解読できます。

  • SSH暗号化。
    ところで、SSH暗号化は非対称ではありません（パブリック）。認証は非対称です（ [〜＃〜] dh [〜＃〜] （ Diffie-Hellman ）（パスワードの場合）または RSA、DSA、Ed25519鍵の強度 またはその他（公開鍵の場合））、その認証から対称鍵が生成され、通信暗号化鍵として使用されます。

  • 認証に使用されます。
    しかし、SSHに対して、（ssh-keygenで生成された）公開鍵は追加の秘密を保持します：公開鍵の所有者を認証します。

    インターネットから公開鍵を受け取った場合：それが誰の所有者であるかをどのようにして知るのですか？公開鍵が主張するものは何でも信頼できますか？貴方はするべきではない ！！

    そのため、公開鍵ファイルをリモートサーバーに（安全な方法で）運び、そこにインストールする必要があります。その後、その（既に検証済みの）公開鍵を、そのサーバーへのログインを認証する方法として信頼できます。

Q3

以前は主にテストのためにVPSからクライアントBに接続したことがありましたが、それはすでに公開鍵を交換していませんか？

暗号化に使用される1組の公開鍵（DH生成の公開鍵のセット）を交換します。 ssh-keygenで生成された authentication 公開鍵ではありません。その通信で使用されたキーは、通信が閉じられると消去され、忘れられます。

また、リモートサーバーのIPを認証するためのキーを受け入れ（そして使用）しました。 IPが安全であることを保証するには、単純な（ ?? ）公開鍵認証よりもさらに複雑になります。

私の印象では、公開鍵は共有できますが、秘密鍵またはパスフレーズは安全に保管する必要があります。

そして、あなたの（一般的な）印象は正しいですが、悪魔は細部にあります...

誰がキーペアを生成したかによって、セキュリティが低下することなく公開キーが公開されます。

誰が公開鍵を受け取るか必須独立して公開鍵の所有者であることを確認します。

それ以外の場合、公開鍵の受信者が悪意のあるパートナーと通信している可能性があります。

キーを生成

8
Isaac