Loading article…
セキュアシェルプロトコル（SSHプロトコル）は、安全でないネットワーク上でネットワークサービスを安全に運用するための暗号化ネットワークプロトコルです。[ 1 ]最も注目すべき用途は、リモートログインとコマンドライン実行です。
SSHは、Telnetや、 Berkeley Remote Shell（rsh）や関連するrloginおよびrexecプロトコルなど、パスワードなどの安全性の低い平文認証方法を使用する安全性の低いリモートUnixシェルプロトコルの代替として、 Unixライクなオペレーティングシステム向けに設計されました。
TelnetやRemote Shellのようなメカニズムはリモートコンピュータにアクセスして操作するように設計されているため、これらのコンピュータへのアクセスに必要な認証トークン（ユーザー名とパスワードなど）を安全でない方法で公共ネットワーク経由で送信すると、第三者がパスワードを入手し、Telnetユーザーと同じレベルのリモートシステムへのアクセス権限を取得してしまうという大きなリスクが生じます。Secure Shellは、傍受者がデータストリーム全体にアクセスできる場合でも、送信内容を隠すことを目的とした暗号化メカニズムを使用することで、このリスクを軽減します。[ 2 ]
フィンランドのコンピュータ科学者タトゥ・ユロネンは1995年にSSHを設計し、rshとrloginの安全な代替として、 sshとsloginという2つのコマンドの形で実装を提供しました。その後、プロトコルスイートの開発は複数の開発者グループで進められ、実装のさまざまなバリエーションが生まれました。プロトコル仕様では、SSH-1とSSH-2と呼ばれる2つの主要なバージョンが区別されています。最も一般的に実装されているソフトウェアスタックはOpenSSHで、1999年にOpenBSD開発者によってオープンソースソフトウェアとしてリリースされました。実装は、組み込みシステムを含む、一般的に使用されているすべてのタイプのオペレーティングシステム向けに配布されています。
SSH アプリケーションはクライアント/サーバー アーキテクチャに基づいており、SSH クライアントインスタンスをSSH サーバーに接続します。[ 3 ] SSH は、3 つの主要な階層コンポーネントで構成される階層型プロトコル スイートとして動作します。トランスポート層は、サーバー認証、機密性、および完全性を提供します。ユーザー認証プロトコルは、サーバーに対してユーザーを検証します。接続プロトコルは、暗号化されたトンネルを複数の論理通信チャネルに多重化します。[ 1 ]
SSHは公開鍵暗号方式を使用してリモートコンピュータを認証し、必要に応じてユーザーを認証できるようにします。[ 3 ]
SSHは様々な方法で使用できます。最もシンプルな方法では、通信チャネルの両端で自動生成された公開鍵と秘密鍵のペアを使用してネットワーク接続を暗号化し、その後パスワードを使用してユーザーを認証します。
公開鍵と秘密鍵のペアをユーザーが手動で生成する場合、認証は基本的に鍵ペアが作成された時点で実行され、パスワードの入力を求められることなくセッションが自動的に開かれることがあります。このシナリオでは、公開鍵は、対応する秘密鍵の所有者が秘密に保持する、アクセスを許可する必要のあるすべてのコンピュータに配置されます。認証は秘密鍵に基づいて行われますが、認証中に鍵がネットワーク経由で転送されることはありません。SSHは、公開鍵を提供する人物が、対応する秘密鍵も所有していることを確認するだけです。
SSHのすべてのバージョンにおいて、未知の公開鍵を検証する、つまり公開鍵をIDと関連付けてから有効なものとして受け入れることが重要です。検証せずに攻撃者の公開鍵を受け入れると、権限のない攻撃者が有効なユーザーとして認証されてしまいます。
Unix ライクなシステムでは、承認された公開鍵のリストは通常、リモートでログインできるユーザーのホーム ディレクトリのファイルに保存されます~/.ssh/authorized_keys。[ 4 ]このファイルは、所有者と root 以外が書き込みできない場合にのみ SSH によって尊重されます。リモート エンドに公開鍵が存在し、ローカル エンドに一致する秘密鍵が存在する場合、パスワードを入力する必要はなくなります。ただし、セキュリティをさらに強化するために、秘密鍵自体をパスフレーズでロックすることができます。
秘密鍵は標準的な場所に保存されている場合もありますし、コマンドライン設定（-isshのオプション）で完全なパスを指定することもできます。ssh -keygenユーティリティは、公開鍵と秘密鍵を常にペアで生成します。
SSHは通常、リモートコンピュータのシェルまたはコマンドラインインターフェイス（CLI）にログインし、リモートサーバー上でコマンドを実行するために使用されます。また、トンネリング、TCPポートの転送、X11接続のメカニズムもサポートしており、関連するSSHファイル転送プロトコル（SFTP）またはセキュアコピープロトコル（SCP）を使用してファイルを転送することもできます。[ 3 ]
SSH はクライアント/サーバー モデルを使用します。SSHクライアントプログラムは通常、リモート接続を受け入れる sshd などのSSHデーモンへの接続を確立するために使用されます。どちらも、 macOS 、ほとんどのLinuxディストリビューション、OpenBSD、FreeBSD、NetBSD、Solaris、OpenVMSなど、ほとんどの最新のオペレーティングシステムに一般的に存在します。特に、Windows 10 バージョン 1709 より前のバージョンのWindowsには、デフォルトでは SSH は含まれていませんが、さまざまなレベルの複雑さと完全性を持つプロプライエタリ、フリーウェア、オープンソースのバージョンが存在していました ( SSH クライアントの比較を参照)。2018 年にMicrosoft はOpenSSHソース コードを Windows に移植し始め[ 5 ] 、 Windows 10 バージョン 1709では、OpenSSH の公式 Win32 ポートが利用可能になりました。
UNIX ライクなシステム ( Konquerorなど)のファイルマネージャは、 FISHプロトコルを使用して、ドラッグ アンド ドロップ機能を備えた分割ペイン GUI を提供できます。オープンソースの Windows プログラムWinSCP [ 6 ]は、バックエンドとしてPuTTYを使用して同様のファイル管理 (同期、コピー、リモート削除) 機能を提供します。WinSCP [ 7 ]と PuTTY [ 8 ]はどちらも、クライアント マシンにインストールする必要なく、USB ドライブから直接実行できるようにパッケージ化されています。ChromeOS の Crostini には、デフォルトで OpenSSH が付属しています。Windows で SSH サーバーを設定するには、通常、設定アプリで機能を有効にする必要があります。
SSHは、クラウドコンピューティングにおいて接続性の問題を解決し、クラウドベースの仮想マシンをインターネットに直接公開することによるセキュリティ上の問題を回避できる点で重要です。SSHトンネルは、インターネット上、ファイアウォールを介して仮想マシンへの安全な経路を提供できます。[ 9 ]
IANAは、このプロトコルにTCPポート22、UDPポート 22、SCTPポート 22を割り当てています。 [ 10 ] IANA は、2001 年という早い時期に、SSH サーバー用の標準 TCP ポート 22 を既知のポートの 1 つとしてリストしていました。 [ 11 ] SSH は、接続指向トランスポート層プロトコルとして TCP の代わりにSCTPを使用して実行することもできます。 [ 12 ]
1995年、フィンランドのヘルシンキ工科大学の研究者であるタトゥ・ユロネンは、大学のネットワークで発生したパスワードスニッフィング攻撃をきっかけに、プロトコルの最初のバージョン（現在はSSH-1と呼ばれている）を設計した。[ 13 ] SSHの目標は、強力な認証や機密性の保証を提供しない以前のrlogin、telnet、FTP [ 14 ]、およびrshプロトコルを置き換えることであった。彼はポート番号22を選んだのは、それが（ポート23）と（ポート21）の間にあるからである。[ 15 ]telnetftp
Ylönenは1995年7月に自身の実装をフリーウェアとして公開し、このツールは急速に人気を集めた。1995年末までに、SSHユーザーベースは50か国で2万人にまで拡大した。[ 16 ]
1995年12月、イロネンはSSHの販売と開発を行うためにSSH Communications Securityを設立した。SSHソフトウェアの初期バージョンはGNU libgmpなどの様々なフリーソフトウェアを使用していたが、SSH Communications Securityがリリースした後のバージョンは次第に独自ソフトウェアへと進化していった。
2000年までにユーザー数は200万人に達したと推定されている。[ 17 ]
2006年、「secsh」というワーキンググループで議論された後、[ 18 ] SSHプロトコルの改訂版であるSSH-2が標準として採用されました。[ 19 ]このバージョンはセキュリティと新機能が向上していますが、SSH-1とは互換性がありません。たとえば、Diffie-Hellman鍵交換などの新しい鍵交換メカニズム、クライアントとサーバー間でネゴシエートできるMD5やSHA-1などのメッセージ認証コードによるデータ整合性チェックの改善などが導入されています。SSH-2では、 AESなどのより強力な暗号化方式も追加されており、最終的には3DESなどの以前の標準の弱くて侵害された暗号が置き換えられました。[ 20 ] [ 21 ] [ 19 ] SSH-2の新機能には、単一のSSH接続で任意の数のシェルセッションを実行できる機能が含まれます。 [ 22 ] SSH-2 は SSH-1 よりも優れており人気があるため、libssh (v0.8.0+)、 [ 23 ] Lsh [ 24 ]やDropbear [ 25 ]などの実装は最終的に SSH-2 プロトコルのみをサポートするようになりました。
2006年1月、バージョン2.1が確立されてからかなり経って、RFC 4253では、2.0およびそれ以前のバージョンをサポートするSSHサーバーは、プロトコルバージョンを1.99として識別する必要があると規定されました。[ 26 ]このバージョン番号は、過去のソフトウェア改訂を反映したものではなく、後方互換性を識別するための方法です。
1999年、フリーソフトウェア版の入手を望んだ開発者たちは、オープンソースライセンスの下で最後にリリースされたオリジナルのSSHプログラムのバージョン1.2.12からソフトウェア開発を再開した。[ 27 ]これは、ビョルン・グロンヴァルのOSSHソフトウェアのコードベースとして機能した。[ 28 ]その後まもなく、OpenBSDの開発者たちはグロンヴァルのコードをフォークしてOpenSSHを作成し、OpenBSDのリリース2.6に同梱した。このバージョンから、OpenSSHを他のオペレーティングシステムに移植するための「移植性」ブランチが形成された。[ 29 ]
2005年現在OpenSSHは、多くのオペレーティングシステムディストリビューションでデフォルトバージョンとして採用され、最も人気のあるSSH実装でした。一方、OSSHは廃止されました。[ 30 ] OpenSSHは引き続きメンテナンスされており、SSH-2プロトコルをサポートしていますが、OpenSSH 7.6リリースでコードベースからSSH-1のサポートを削除しました。
2023年、博士課程学生のフランソワ・ミシェルとオリヴィエ・ボナヴァンチュール教授によって、従来のSSHに代わるものとしてSSH3 [ 31 ] [ 32 ] [ 33 ]が提案され、そのコードはオープンソース化されました[ 34 ] 。この新しいバージョンは、オリジナルのSSH接続プロトコルを実装していますが、 QUIC上で動作するHTTP/3上で動作します。以下のような複数の機能を提供します。
しかし、SSH3という名称は議論の対象となっており、プロジェクトはより適切な名称に変更することを目指している。[ 35 ]この議論は、この新しい実装がSSHプロトコルを大幅に改訂しているため、SSH3と呼ぶべきではないという事実から生じている。
SSHは、多くのプラットフォームで様々なアプリケーションに使用できるプロトコルです。これには、ほとんどのUnix系OS（Linux、AppleのmacOSを含むBSD系OS、Solarisなど）やMicrosoft Windowsが含まれます。ただし、以下のアプリケーションの中には、特定のSSHクライアントまたはサーバーでのみ利用可能または互換性のある機能を必要とするものがあります。例えば、SSHプロトコルを使用してVPNを実装することは可能ですが、現状ではOpenSSHサーバーとクライアントの実装でのみ可能です。
セキュアシェルプロトコルは、いくつかのファイル転送メカニズムで使用されています。
SSHプロトコルは、3つの独立したコンポーネントからなる階層構造を採用しています。
このオープンアーキテクチャは、非常に高い柔軟性を提供し、セキュアシェル以外にも様々な用途でSSHを利用できます。トランスポート層の機能だけでも、トランスポート層セキュリティ（TLS）に匹敵します。ユーザー認証層は、カスタム認証方式で高度に拡張可能です。また、接続層は、複数のセカンダリセッションを単一のSSH接続に多重化する機能を提供します。これはBEEPに匹敵する機能であり、TLSでは利用できません。
1998年、SSH 1.5に脆弱性が報告されました。この脆弱性は、このバージョンのプロトコルで使用されているCRC-32のデータ整合性保護が不十分なため、暗号化されたSSHストリームに不正にコンテンツを挿入できるというものでした。 [ 42 ] [ 43 ] SSH Compensation Attack Detector [ 44 ]と呼ばれる修正がほとんどの実装に導入されました。これらの更新された実装の多くには、新しい整数オーバーフローの脆弱性[ 45 ]が含まれており、攻撃者はSSHデーモンの権限（通常はroot）で任意のコードを実行できるようになってしまいました。
2001年1月、攻撃者がIDEAで暗号化されたセッションの最後のブロックを変更できる脆弱性が発見されました。[ 46 ]同じ月に、悪意のあるサーバーがクライアント認証を別のサーバーに転送できる別の脆弱性が発見されました。[ 47 ]
SSH-1には設計上の欠陥があり、脆弱性があるため、現在では一般的に廃止されていると考えられており、SSH-1へのフォールバックを明示的に無効にすることで使用を避けるべきです。ほとんどの最新のサーバーとクライアントはSSH-2をサポートしています。[ 47 ]
2008 年 11 月、SSH のすべてのバージョンに理論上の脆弱性が発見されました。この脆弱性により、当時標準のデフォルト暗号化モードであったCBCを使用して暗号化された暗号文ブロックから、最大 32 ビットの平文を復元することが可能でした。[ 48 ]最も簡単な解決策は、 CBC モードの代わりにCTR (カウンターモード) を使用することです。これにより、SSH はこの攻撃に対して耐性を持つようになります。[ 48 ]
2014年12月28日、シュピーゲル誌は内部告発者エドワード・スノーデンによってリークされた機密情報[ 49 ]を掲載し、国家安全保障局がSSHトラフィックの一部を解読できる可能性があることを示唆した。そのようなプロセスに関連する技術的な詳細は明らかにされなかった。2017年のCIAハッキングツールBothanSpyとGyrfalconの分析では、SSHプロトコルは侵害されていないことが示唆された[ 50 ] 。
2023年に、現在のほとんどのssh実装に対する新しい中間者攻撃が発見されました。発見者によってテラピン攻撃と名付けられました。 [ 51 ] [ 52 ]しかし、この攻撃は正規のsshセッションを傍受する必要があり、攻撃の範囲が限定されているため、ほとんどの場合接続が失敗するという偶然の結果となり、リスクは軽減されます。[ 52 ] [ 53 ] ssh開発者は、この攻撃の主な影響はsshのキーストロークタイミング難読化機能を低下させることだと述べています。 [ 53 ]この脆弱性はOpenSSH 9.6で修正されましたが、修正を完全に有効にするにはクライアントとサーバーの両方をアップグレードする必要があります。
IETFの「secsh」ワーキンググループによる以下のRFC文書は、SSH-2を提案されているインターネット標準として文書化しています。
プロトコルの仕様は、その後、以下の出版物によって更新されました。
さらに、OpenSSHプロジェクトには、いくつかのベンダー独自のプロトコル仕様／拡張機能が含まれています。
いずれにせよ、ossh は古くて時代遅れなので、使用はお勧めしません。