SSLとSSHはどちらも、完全性がチェックされた機密データ転送用のトンネルを構築するための暗号化要素を提供します。その部分では、同じような手法を使用しており、同じ種類の攻撃を受ける可能性があるため、両方が適切に実装されている場合は、同様のセキュリティ（つまり、優れたセキュリティ）を提供する必要があります。両方が存在するのは一種の [〜＃〜] nih [〜＃〜] シンドローム：SSH開発者はトンネル部分にSSLを再利用する必要がありました（SSLプロトコルは多くのバリエーションに対応するのに十分な柔軟性があります）証明書を使用しないことを含む）。
彼らはトンネルの周りにあるもので異なります。 SSLは従来、サーバーとクライアントの公開鍵をアナウンスするためにX.509証明書を使用しています。 SSHには独自のフォーマットがあります。また、SSHには一連のプロトコルが付属していますinsideトンネル（複数の転送の多重化、トンネル内でのパスワードベースの認証の実行、端末管理など）。SSLにはそのようなものはありません。 、またはより正確には、そのようなものがSSLで使用されている場合、それらはSSLの一部とは見なされません（たとえば、SSLトンネルでパスワードベースのHTTP認証を行う場合、「HTTPS」の一部であると言いますが、これは、SSHで発生する現象と同様に機能します。
概念的には、SSHを使用して、トンネル部分をSSLのものと置き換えることができます。 HTTPSを使用して、SSLをSSH-with-data-transportおよびサーバーの公開鍵を証明書から抽出するフックに置き換えることもできます。科学的に不可能ではなく、適切に行われれば、セキュリティは同じままです。ただし、そのための広範な規則や既存のツールはありません。
したがって、SSLとSSHは同じものには使用しませんが、これは、これらのプロトコルの実装に歴史的に付属しているツールが原因ですnotセキュリティ関連の違いにより。また、SSLまたはSSHを実装する場合は、両方のプロトコルでどのような攻撃が行われたかを確認することをお勧めします。
これは妥当な比較ではありません。 SSLはネットワーク経由で転送されるデータを保護するための一般的な方法ですが、SSHはログインしてリモートコンピューターとデータを共有するためのネットワークアプリケーションです。
SSHのトランスポート層保護はSSLと機能が似ているため、「より安全」なのは、特定の脅威モデルが何を求めているか、およびそれぞれの実装が対処しようとしている問題に対処しているかどうかによって異なります。
SSHには、SSLにはないユーザー認証レイヤーがあります（SSLは必要ないため、SSLは、SSHが実行できる2つの接続インターフェースを認証するだけで十分です）。 UTF-8アートの場合：
SSL SSH
+-------------+ +-----------------+
| Nothing | | RFC4254 | Connection multiplexing
+-------------+ +-----------------+
| Nothing | | RFC4252 | User authentication
+-------------+ +-----------------+
| RFC5246 | | RFC4253 | Encrypted data transport
+-------------+ +-----------------+
攻撃の可能性が高い問題に関しては、SSHの方が攻撃範囲が広いことは明らかです。しかし、それはSSHにアプリケーション全体が組み込まれているからです。SSL +提供する必要のあるすべてのアプリケーションの攻撃面は、十分な情報がないため比較できません。
厳密な暗号化の観点からは、どちらも認証された暗号化を提供しますが、2つの異なる方法があります。
SSHは、いわゆる暗号化とMACを使用します。つまり、暗号化されたメッセージは、クリアメッセージのメッセージ認証コード（MAC）に並置されて、整合性を追加します。これは常に完全に安全であるとは証明されていません（実際のケースでは十分であるとしても）。
SSLはMAC-then-Encryptを使用します。MACはクリアテキストに並置され、両方とも暗号化されます。一部のブロック暗号モードでは、MACの一部が推測され、暗号上で何かが明らかになる可能性があるため、これも最適ではありません。これにより、TLS 1.0（BEAST攻撃）の脆弱性につながりました。
したがって、これらには両方の潜在的な理論上の弱点があります。最も強力な方法はEncrypt-then-MAC（暗号化されたメッセージのMACを追加する）です。これは、たとえばIPsec ESPに実装されています。
この比較には見落としていた側面があると思います。 user185は近くに来ましたが、そこまでは行きませんでした。私はこれらがリンゴとオレンジであることに同意し、HTTPSとSSHのほうがリンゴとリンゴの比較に優れていると感じています。 HTTPSとSSHは、OSIモデルの異なるレイヤーを利用するため、送信のさまざまな時点でデータを暗号化します。次に、このデータが送信中に暗号化され、暗号化解除されるのはいつかという質問に答える必要があります。これにより、潜在的な攻撃面が明らかになります。 HTTPSでは、パケットが宛先ネットワークのデバイス（Webサーバー、ボーダールーター、ロードバランサーなど）によって受信されると、暗号化されずに残りのテキストがプレーンテキストで送信されます。現時点ではトラフィックが内部にあるため、これは大した問題ではないと多くの人が主張しますが、ペイロードに機密データが含まれている場合、そのペイロードは暗号化されずに通過するすべてのネットワークデバイスのログファイルに保存されます。最終目的地。 SSHでは、通常、宛先デバイスが指定され、このデバイスに到達するまで送信が暗号化されます。 HTTPSデータを再暗号化する方法はいくつかありますが、これらは環境にHTTPSソリューションを実装するときにほとんど忘れてしまう追加の手順です。
sshは鍵（非公開）およびロック（公開）のようなものです
sslはドアとレンガのようなものです。
sslは、2つのコンピューターサーバー間の安全なリンクを提供します。たとえば、あなたとあなたが接続しているもの。
sshは、接続しているコンピューターがそれ自体を確認し、アクセスする方法です。
問題は2つあり、暗号化の長所と短所だけではありません。しかし、それは配達の容易さと便利さです。したがって、ビジネスの観点から見ると、SSL/TLSはブラウザとパブリックまたはプライベート証明書のいずれかが必要なだけなので、より便利で簡単です。
また、SSHを使用するには、アプリケーションまたはシンクライアントをインストールする必要があります。これは、ユーザーのインターネットクライアントの観点とサポートの問題です。
すべてのユーザー、特にテクノロジーに挑戦したユーザーが明るいわけではありません。
私の2セント。
SSLは、トンネリングされるコンテンツから抽象化されたプロトコルレイヤーです。 SSHはシェル（SH）の安全なバージョンであり、その下に抽象層を含めるようには設計されておらず、特にシェルトラフィックを伝送するように設計されています。したがって、両方で暗号化操作が使用され、それらの暗号化操作は同じである可能性もありますが、目的、したがって全体的な設計はかなり異なります。
（上記で引用したように）特定の違いがあることを覚えておいてください。しかし、それらの違いのすべてではないにしても、ほとんどが異なるプロトコルの目的に根ざしています。