SSH は Telnet とどう違うのですか?
公開: 2023-03-15
SSH と TELNET の両方を使用すると、リモートのネットワーク化されたコンピューターに接続して、それらのコンピューターの前に座っているかのようにそれらを使用できます。 では、これら 2 つの由緒あるプロトコルの違いは何でしょうか? また、TELNET 経由で SSH を使用する利点は常にあるのでしょうか?
TELNET と SSH: 起源の話
必要は発明の母。 システム管理者は、物理的に別の場所にあるコンピューターにアクセスして管理する方法を必要としていました。 管理者がコンピューターの前に立つことが現実的でない、または不便な場合、リモート コンピューターにアクセスして、そのコンピューターにコマンドを入力しているかのようにコマンドを発行できる方法が必要でした。
TELNET ( tel etype over Network Protocol の略) は、この問題に対する答えとして 1969 年に開発されました。 リモート コンピューターがネットワークにアクセスできる限り、管理者またはその他の承認された人物がリモート キーボードのキーを物理的に押しているかのように、リモート コンピューターに接続して使用することができました。
SSH は、Telnet やその他の同様のソリューションへの直接的な対応として、1995 年に作成されました。 今回の必要性はセキュリティでした。 その時代の TELNET、rlogin、FTP、およびその他のプロトコルは、セキュリティを考慮せずに、またはその必要性を認識せずに設計されました。
SSH はセキュアシェルの略であり、セキュリティが当初から指針となる原則であったことがわかります。 現在、SSH はほぼ完全に TELNET に取って代わりました。
TELNET は平文セキュリティの悪夢
TELNET の大きな問題は、平文を使用していることです。 ユーザー名やパスワードを含め、トラフィックは暗号化されません。 ネットワークに沿って送信されるものはすべて、パケット スニッフィングによってキャプチャされ、非常に簡単に読み取ることができます。 あなたが唯一のユーザーでない限り、これはローカル ネットワークでもセキュリティ リスクです。 すべてのユーザーが TELNET トラフィックを傍受し、権限のないログイン資格情報を取得できます。
リモート コンピュータがオフサイトにあり、インターネット経由で接続する必要がある場合、問題は計り知れないほど大きくなります。 TELNET は当時の製品であり、公平を期すために言えば、著者は、今日の大きく異なる IT 環境で、人々が 50 年以上後に TELNET を使用することになるとはほぼ確実に予想していませんでした。
TELNET は、今日の私たちをまとめて助けてくれた重要なプログラムのリストに載るに値するものですが、今日の世界でまだ使用すべきものではありません。
SSH と TELNET の違いは?
一見すると、TELNET と SSH は同じ問題に対する 2 つの答えです。 どちらも、リモート コンピューターのターミナル ウィンドウにアクセスしてコマンドを発行できます。 しかし、SSH は TELNET よりもずっと後に開発されたため、問題はより完全に理解され、解決策はより適切に設計されました。
TELNET はプライベートネットワークを念頭に置いて設計されましたが、SSH はパブリックネットワークに対応するように設計されており、データを転送してリモート接続を行うときにプライバシーとセキュリティを維持する必要があります。
TELNET はポート 23 を使用し、そのポート番号は変更できません。 デフォルトでは、SSH はポート 22 を使用しますが、これは構成および変更できます。 わかりにくいポート番号を使用するように SSH を構成すると、攻撃者が SSH ポートを特定するのが難しくなります。 SSH ポートを特定できれば、自動化されたソフトウェアによって、データ侵害から収集された何千ものパスワードが順番に試行されるブルート フォース攻撃を開始するのは簡単なことです。
さらに良いことに、SSH はパスワードをまったく不要にできます。 公開キー暗号化を使用して、リモート コンピューターへの認証を行うことができます。 パスワードをリモート コンピューターに送信する必要がないため、パスワードはまったく送信されません。 そのデータ暗号化と SSH キー認証は、SSH がインターネットのような安全でないネットワーク上で安全な接続と通信を提供できることを意味します。
実際、SSH サーバーを実行しているリモート コンピューターだけでなく、さまざまなサービスでの認証に SSH を使用できます。 たとえば、パスワードの代わりに SSH を使用して、GitHub、GitLab、および BitBucket がホストする Git リポジトリにアクセスできます。
SSH over TELNET を使用するもう 1 つの利点は、SSH がリバース SSH トンネリングを実行できることです。 これには、サーバーがクライアント コンピューターとの接続を確立する必要があります。 ローカル ユーザーがサーバーへの接続を確立するまで、接続は無視されます。
クライアントがサーバーに接続する場合、ユーザーは自分のコンピューターへの SSH 接続を確立します。 SSH は、既に確立されている接続を介して接続をサーバーに送信します。 これにより、サーバーからクライアントへの暗号化済み接続内にプライベート トンネルが提供されます。
TELNET の唯一の利点は、使用する帯域幅が少ないことです。 しかし、これは帯域幅が不足していた 1969 年ではありません。また、SSH も正確に帯域幅を浪費しているわけではありません。
SSHにも問題がありました
SSH はセキュリティに関しては TELNET よりも優れていますが、SSH は依然としてソフトウェアであり、ソフトウェアにはバグがある可能性があることを覚えておく必要があります。 これらのバグは、サイバー犯罪者が悪用できる脆弱性につながる可能性があります。 また、暗号化の標準とアルゴリズムは時間の経過とともに変化し、取って代わられます。 すべての暗号化ベースのソフトウェアと同様に、SSH の古いバージョンが古くなると、安全性が低下する可能性があります。 そのため、SSH の最新リリースを使用していることを確認することが重要です。
ほとんどの Linux コンピューターで使用されている SSH のバージョンは OpenSSH です。これは、OpenSSL ツールキットとライブラリに基づいて構築された SSH の実装です。 2012 年に、OpenSSL ライブラリは、攻撃者が SSL サーバーからの応答を要求し、応答に含めるデータの量を指定することを可能にするバグを誤って導入しました。
実際の応答が 64 バイトしか必要としない場合でも、(たとえば) 64KB の応答を要求できます。 そのデータの最初のバイト シーケンスは、本物の期待される応答であり、その後に、最近 OpenSSL によって使用されたメモリ内にあったものが続きます。 そのデータに含まれていたのは偶然でしたが、セッション Cookie やパスワードなどの機密情報や、攻撃者が秘密鍵を取得できるようなその他の情報が含まれている可能性がありました。
2014 年に発見されると、この脆弱性は Heartbleed として知られるようになりました。 ソフトウェアですぐに修正されました。 ただし、脆弱性はその時点で消えません。 脆弱性は、脆弱なソフトウェアを実行しているすべてのコンピューターに修正済みバージョンがインストールされている場合にのみ、完全に無効になります。 つまり、コンピュータにパッチが適用されたときです。 多くの管理者の対応が遅かったため、修正されたソフトウェアの取り込みは遅かった。
また、バグが導入された 2012 年から発見され、対処された 2014 年までの 2 年間も心配です。 この 2 年間、OpenSSL の脆弱なバージョンを実行しているすべての SSH サーバーが危険にさらされていました。
公平を期すために言うと、それはほぼ 10 年前に発生し、それ以来、多くのリリース、改善、バグ修正、およびコード レビューが行われてきました。
関連: SSH サーバーを保護する最良の方法
SSH または TELNET を使用する必要がありますか?
今日、TELNET を使用する必要がある理由を考えるのは困難です。 それは、TELNET を安全に使用できるシナリオがあると言っているのと同じではありません。 外の世界に接続されていない自己完結型のネットワークでは、トラフィックのパケットを盗聴する人がいないことが確実な場合は、TELNET を使用できます。 しかし、する理由はありません。 セキュリティのトレードオフは正当化できません。
SSH はより安全で柔軟です。これが TELNET 経由で SSH を使用する利点です。 OpenSSH の実装は、商用を含むすべての用途で無料であり、一般的なすべてのオペレーティング システムで利用できます。
関連: Windows、macOS、または Linux から SSH サーバーに接続する方法