時々必要 ソケットを介してデータを送信する Telnet接続、FTPファイルのダウンロード、SQLクエリ、その他の種類の送信など、異なるマシン間。
そのデータはネットワークを介して生で移動するため、 安全でない、つまり、起点と終点の間のパス上にある任意のノードによって傍受される可能性があります。 強盗.
このデータがキャプチャされるのを防ぐことはできませんが、第三者によって解釈および理解され、通信が暗号化されるのを防ぐことができます。
SSH 私たちができるツールです 安全な接続 マシン間。 その最も一般的な使用法は、コマンドインタープリターにリモートで接続することです。
ただし、作成などの他の可能性もあります 暗号化されたトンネル 異なるマシン間。
host1からhost2にtelnetしたいとします。
host1$ telnet host2
このコミュニケーションは完全にオープンであり、 傍受。 これを保護するために、ホスト5000の任意に選択したポート（たとえば1）をホスト23のポート2（telnet）にリダイレクトします。
このようにして、host5000のポート1に送信されたすべてのデータを取得し、sshがhost22のポート2を介して開いたトンネルを暗号化して移動し、host23のポート2にリダイレクトして、最終的な宛先に到達します。
これを行うには、host2のユーザー名とパスワードを知っている必要があります。
トンネルを開くには、次のように記述します。
host1$ ssh -R 5000:localhost:23 usuariohost2@host2
まあ：
host1$ ssh -L 5000:host2:23 usuariohost2@host2
どちらのオプションも同等です。 telnet接続を確立するために、host2ではなく、host1で選択されたポートを参照します。
host1$ telnet localhost 5000
これにより、telnetであろうとなかろうと、あらゆる通信を安全にします。 もう少し調べてみると、 SSH これらのリダイレクトは、サードマシンに対しても行うことができます。これにより、単一のエントリポイントで、LAN全体から別のLANに安全にアクセスできます。
理論は非常に興味深いように見えますが、実際の事例を見ればさらに興味深いでしょう。
しかし、真実は、私が背が低いにもかかわらず、私はその記事が好きだったということです。
たぶんあなたがインスピレーションを得たウィキを見て https://wiki.archlinux.org/index.php/Secure_Shell#Forwarding_other_ports
と同じですが、autosshセクション https://wiki.archlinux.org/index.php/Secure_Shell#Autossh_-_automatically_restarts_SSH_sessions_and_tunnels
実際、ストリーミングであれ、ホストへの接続であれ、sshで送信できるものは何でも。 等xの理由で、それらを暗号化する必要があります。
およびsecurecrtルール
私は時々SSHを非常に基本的なレベルで使用します。 デフォルトのポートは22ですよね？
したがって、正しく理解していれば、私のPCはホスト1であり、接続したいのはhost2です。このトンネルは、ポート5000とそのポート23の間に接続を作成し、最終的にポート22になりますか？
なぜポートを切り替える理由ですか？ ポート22でトンネルを作成できますか？
非常に興味深い記事。 ナノのように、もっと欲しい！
SSHは実際にデフォルトでポート22を使用します（変更は可能ですが）。 このポートは、5000つのホスト間の実際の通信で使用されるポートです。 それはあなたがそれが開いていて、ファイアウォールがそれを遮断していないことを確認しなければならないものです。 しかし、ユーザーにとっては完全に透過的です。 あなたはそれを忘れることができます。 この例では、リダイレクトはポート23と5000の間です。心配する必要があるのはこれら23つだけです。 ユーザーには、ホストのポートXNUMXに送信するすべてのものが、宛先ホストのXNUMXに表示されることがわかります。
明らかに、各ユーザーは自分が適切と考えるポートをリダイレクトできます。
コメントしてくれてありがとう。 これは私の最初の投稿であり、あなたの意見は次の投稿をより良くするのに役立ちます。
それはVPSでも実行できますか？
これは私の場合です。PC1はサーバーにアクセスできますが、PC2はアクセスできません。どちらもsshで接続します。PC2にアクセスしたいのですが、PC1のどのポートをリダイレクトしますか？ 実際に必要なのは、PC2からサーバーポートに到達することであり、パケットの送信元IPとしてPC1が含まれている場合です。 分かりますか？
あなたは自分自身を理解させます。 この場合、PC1のポートをサーバーのポート2にリダイレクトするためにPC22が必要です。
PC2 $ ssh -L 5000：サーバー：22ユーザーPC1 @ PC1
そして、この接続を開いたままにして、別の端末から：
PC2 $ ssh userServer @ localhost -p 5000
そして、あなたはすでに中にいます。
最後に機能的な解決策!! Getafixに感謝します、あなたは私に可能性の世界を与えてくれました!!
私は嬉しい！
素晴らしい記事。ようこそ DesdeLinux ????
そして、22がブロックされた場合はどうすればよいですか？ 笑..
elavに感謝します。
ポート22がブロックされている場合、うーん、XDファイアウォールをハックするための代替手段を探す必要があります
そして何よりも最悪の（仮想）：VPSプロバイダーによってブロックされていること。
数時間前に質問をして試験をしました😛
私はそれを言わないでしょう：
host1 $ ssh -R 5000：localhost：23 userhost2 @ host2
これは、他のコマンドラインと同等です...- Lを使用したものです。
-Rは、新しい接続に対して開かれているポートがリモート側、つまりsshサーバー側にあることを示しているためです。 -Lはローカル側でポートを開き、クライアント側で新しい接続を受信します。
行の翻訳：
host1 $ ssh -R 5000：localhost：23 userhost2 @ host2
これは次のようになります。host1にいる場合、ユーザーuserhost22を使用してhost2のsshサーバー（ポート2）に接続し、host5000のリモートポート2で生成された接続をhost23（my localhost）のポート1に転送します。
そうでない場合は、私を訂正してください！ 😉
—–
一方、サーバーがポート22への接続の入力をブロックした場合、つまり、sshサーバーにリモートで接続することはできません。 できることは; サーバー（リモートhost2システムのファイアウォールの背後にある友人のsysadmin）からコマンドラインが実行されます。
host2 $ nohup ssh -fN -R 6000：localhost：22 userhost1 @ host1
-fはバックグラウンドに移動します
-Nはリモートでコマンドを実行しません
nohupは、ログアウト時にコマンドの実行が中断されるのを防ぎます
host1 $ ssh userhost2 @ localhost -p 6000
このようにして、host1からポート1でlocalhost（同じhost6000）への接続を生成し、リモートシステムhost22のポート2に接続を転送します。ここで、ユーザーhost2でログインします。
これにより、内部から少し助けを借りて、firewalによってブロックされたsshサーバーにログインできるようになります（私は試していませんが、機能しているようです）。 😀
後者はTheGeekStuff誌の説明から読みました
http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel/
私はあなたの出版物が本当に好きです。 よく読む！
ご挨拶。
あなたが正しいです。 記事に誤りがあります。 リダイレクトは同等ではありません。 コマンドhost1 $ ssh -R 5000：localhost：23 userhost2 @ host2は、逆方向のリダイレクトを実行します。つまり、-Lを指定したコマンドとは逆に、リモートポート5000を23ローカルにリダイレクトします。
訂正ありがとうございます。