あなたは何をしましたか？

使ってみましたか？サムSSHコマンド：

1. いつ第二あなたが作ったコンソール：

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

   sshd（サーバー）コマンドでポートを開きます18822。離れてvps:18822ローカルホスト（B）ポート22に接続します。

2. いつ仮想プライベートネットワークあなたが作ったコンソール：

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

   18888使用可能なポートを開くSSH（クライアント）コマンド外部（）0.0.0.0の（）ポートvpsは内部ポート18822に接続されています。

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

3. いつㅏコンソール（そしてただ参加接続）：

   クライアントからの接続ㅏ顧客に直接第二存在するvps:18888。

重要なのは最後の接続です。
完全なSSHセキュリティは次のものです。確認する~のㅏ到着第二。

どういう意味ですか

これSSHプロトコル

SSH は、安全でないネットワークを介してセキュアなチャネルを提供します。

使用してエンドツーエンド暗号化

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

エンドツーエンドの暗号化は概念です。 SSHはプロトコルです。 SSH はエンドツーエンドの暗号化を実装します。 httpsまたは他の暗号化プロトコルも機能します。

もしプロトコルは強力です。そして実装は正しいです。暗号鍵を知っている当事者は2人だけです。検証済み（終了）すべての当事者。

鍵が不明であり、プロトコルのセキュリティを侵害できないため、他の当事者は通信内容から除外されます。

もし、説明通り：クライアントAからクライアントBに直接システムBに直接認証します。それから、クライアントAとクライアントBのみがキーを持っています。他にはありません。

第1四半期

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

発生する通信（日付、時刻、最終IPなど）と特定量のトラフィック（キロバイト、メガバイト）のみを監視できますが、実際に通信しているコンテンツは監視できません。

第2四半期

シナリオB：VPSが完全に破損し、ファイルシステムの内容が変更される可能性があります。

問題ではありません。通信が別のサイト/場所を介して再ルーティングされても、鍵を知っている当事者はAとBだけです。今すぐ：もし通信開始時の認証はAとBの間で行われます。

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

あなたについて知っています〜しなければならない使用された公開鍵がシステムBに安全に渡されていることを確認してください。鍵を渡してから暗号化を渡すために同じチャネルを信頼できません。持つプロトコルを破ることができる中間者攻撃。

第3四半期

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

いいえ、公開鍵が両端に安全に配置されている場合、これが発生する可能性はほとんどありません。

公開鍵の入ったディスクを持って相手に近づいてインストールすればこれ以上心配しなくてもいいです。

コメント

あなたの意見で判断すると、次のようになります。

第1四半期

デフォルトでは、私の設定のVPSはポート転送のみを実行し、クライアントAからBへの実際のSSH接続または認証には関与しません。そうですか？

ほとんど。はい、VPSです。しなければならない認証には関与しません。しかし、これは「中」です。つまり、片側からパケットを受信し（正しく動作している場合）、もう一方に転送します。しかし、代替案があります。 VPS（またはすべての中間デバイス）を選択できます。嘘をつくそして「中間者攻撃」を行う。クライアントBのふりをしてクライアントAにうそをつくことも、クライアントAのふりをしながらクライアントBにうそをつけることもできます。これにより、「中間者」との通信に含まれるすべての内容が明らかになります。だから私が強調する言葉はしなければならない以上。

私また言わなければなりません:

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

パスワードベースの認証はいいえ公開鍵の方法。

認証にパスワードを使用すると、中間者攻撃に対して脆弱になる可能性があります。いくつかの他の選択肢がありますが、これはこの記事の範囲外です。

もともと、SSH-keygenを使用した鍵ペアの生成（A面にあると仮定）、（適切なセキュリティのために）ディスクの公開部分をB面に転送し、認証キーファイルにインストールします。するいいえネットワークインストール公開鍵を使用します。例:ssh-copy-idを使用しないでください本当にインターネット経由するあなたが何をしているのか、そして当事者Bの身元を確認する能力があるかどうかを正確に知ってください。この作業を安全に行うためには、専門家でなければなりません。

第2四半期

しかし、公開鍵は公開ではありませんか？

• はい、公開です。
  はい、そうです。公開 - プライベートペアを作成するエンティティは、公開部分を誰にでも公開でき、秘密は失われません。誰かが公開鍵で暗号化すると、一致する（秘密）秘密鍵ですべてのメッセージを復号化できます。

• SSH暗号化。
  ただし、SSH暗号化は非対称（公開）ではなく対称です。認証は非対称です（またはDH（ディフィー・ヘルマン）（パスワードの場合）またはRSA、DSA、Ed25519 主な強度またはその他（公開鍵の場合））対応する認証に基づいて対称鍵が生成され、通信暗号化鍵として使用されます。

• 認証に使用されます。
  ただし、SSHを使用すると、公開鍵（ssh-keygenを使用して生成）に追加の秘密が提供されます。つまり、公開鍵の所有者を確認します。

  インターネットから公開鍵を受け取った場合、その公開鍵が誰のものであるかをどうやって知ることができますか？公開鍵が主張していると信じていますか？あなたはしないでください！ ！

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

第3四半期

以前はVPSからクライアントBに接続したことがあります（主にテスト用）。公開鍵が交換されていませんか？

暗号化のために公開鍵セット（DHで生成された公開鍵セット）を交換します。いいえ確認するssh-keygenで生成された公開鍵を使用します。通信が終了すると、その通信に使用されたキーは削除され、忘れられます。

また、リモートサーバーのIPを確認するためにキーを受け入れて使用します。 IPセキュリティは単純なものよりも複雑です（??）公開鍵認証。

私の考えでは、公開鍵は共有できますが、秘密鍵やパスワードは安全に保たれるべきです。

あなたの（一般的な）印象は正確ですが、悪魔は詳細にあります...

鍵ペアを作成した人は、セキュリティを損なうことなく自分の公開鍵を公開できます。

公開鍵を受け取る人〜しなければならない 独立して公開鍵が自分が属していると思う人のものであることを確認してください。

そうしないと、公開鍵の受信者が悪意のあるパートナーと通信する可能性があります。

キーの生成