logo

SSH の完全な形式とは何ですか


SSH: セキュアシェル

SSH はセキュア シェルの略です。セキュア ソケット シェルとも呼ばれます。 Secure Shell (SSH) と呼ばれる暗号化ネットワーク プロトコルは、安全でないネットワーク間でネットワーク サービスを安全に運用するために使用されます。クライアント サーバー アーキテクチャは SSH アプリケーションの基礎であり、SSH クライアント インスタンスを SSH サーバーにリンクします。

SSH の完全な形式

Telnet と、Berkeley Remote Shell (rsh) やそれに関連する rlogin および rexec プロトコルなどの安全でないリモート Unix シェル プロトコルの後継として、SSH は、安全でない平文認証トークン通信を使用する Unix 系オペレーティング システム用に作成されました。

意味

SSH はいくつかの異なる方法で適用できます。最も単純な実装では、通信チャネルとネットワーク接続の両端で自動的に生成された公開鍵と秘密鍵のペアを使用してデータを暗号化します。その後、パスワードを使用してユーザーを認証します。ユーザーが公開鍵と秘密鍵のペアを手動で生成すると、その鍵ペアが確立された時点で認証が仮想的に完了し、パスワードを求めるプロンプトが表示されずにセッションを即座に開始できるようになります。

Javaでの有効な識別子
SSH の完全な形式

この場合、所有者は対応する秘密キーを秘密にし、公開キーは所有者にアクセスを許可する必要があるすべてのマシンにインストールされます。秘密キーは認証の基盤として機能しますが、認証の実行時にキーがネットワーク経由で送信されることはありません。 SSH は、公開キーのプロバイダーが対応する秘密キーも保持していることを確認します。

SSH のすべてのバージョンで、不明な公開キーを既知の秘密キーに接続することは、それらを ID 付きの正当な公開キーとして受け入れる前に重要です。攻撃者からの公開キーを検証せずに受け入れると、信頼できない攻撃者を正規のユーザーとして受け入れることになります。

創造

フィンランドのコンピュータ科学者である Tatu Ylönen は、1995 年に初めて SSH を作成しました。プロトコル スイートのさらなる開発は多くの開発者グループで行われ、さまざまな実装の繰り返しが行われました。組み込みシステムを含む、すべての一般的なオペレーティング システムで利用可能な実装があります。 OpenBSD の作成者が 1999 年にオープンソース ソフトウェアとして利用可能にした OpenSSH は、最も頻繁に使用されるソフトウェア スタックです。

認証用の OpenSSH キーの管理

承認された公開キーのリストは、通常、Unix 系システム上の、リモート ログイン権限を持つユーザーのホーム ディレクトリ内のファイル ~/.ssh/authorized key に保存されます。 SSH は、所有者と root 以外のユーザーがこのファイルを変更できない場合にのみこのファイルを尊重します。リモート エンドの公開キーとローカル エンドの一致する秘密キーの両方が存在する場合、パスワードは必要なくなります。ただし、さらに保護を強化するために、パスフレーズを使用して秘密キーをロックする場合があります。また、一般的な場所でシークレット コードを検索することもでき、コマンド ライン オプションを使用して完全なパスを指定することもできます (ssh の場合はオプション -i)。

SSH の完全な形式

SSH はさらに、自動キー生成、暗号化されたパスワードベースの認証を提供します。このシナリオの攻撃者は、信頼できるサーバー側になりすましてパスワードを要求し、パスワードを取得する可能性があります (中間者攻撃)。サーバー側では、パスワード認証をオフにすることができます。

使用

SSH はクライアント/サーバー パラダイムを使用します。通常、SSH はログ記録に使用されます。また、TCP ポートをトンネリングし、X11 接続を転送し、リモート システム上でコマンドを実行することもできます。通常、リモート接続を可能にする SSH デーモンへの接続は、SSH クライアント アプリケーションを使用して行われます。どちらも、macOS、Linux ディストリビューション、OpenBSD、FreeBSD、NetBSD、Solaris、OpenVMS などのほとんどの最新のオペレーティング システムでよく見られます。一部のバージョンはプロプライエタリ、フリーウェア、およびオープン ソースであり、複雑さと包括性の程度はさまざまです (PuTTY や、Cygwin および OpenSSH に含まれる OpenSSH のバージョンなど)。特に、Windows 10 バージョン 1709 までは、Windows バージョンに SSH がデフォルトで含まれていません。

同様のファイル管理 (同期、コピー、およびリモート削除) 機能は、PuTTY をバックエンドとして使用する無料のオープンソース Windows アプリケーション WinSCP によって提供されます。 WinSCP と PuTTY は、クライアント コンピュータにインストールする必要がなく、USB ドライブから直接動作するようにパックされて提供されています。 Windows で SSH サーバーをセットアップするには、多くの場合、設定アプリで機能を有効にすることが必要です。

接続の問題に対処し、クラウドベースの仮想マシンをインターネットに直接公開することによるセキュリティ リスクを防ぐために、SSH はクラウド コンピューティングにおいて重要です。ファイアウォールを介した SSH トンネル仮想コンピュータを通じて、インターネット上の安全な接続が可能になります。このプロトコルに対して、IANA は TCP ポート 22、UDP ポート 22、および SCTP ポート 22 を指定しました。

2001 年の時点で、IANA は SSH サーバーのデフォルトの TCP ポート 22 をウェルノウン ポートの 1 つとして分類しました。コネクション指向のトランスポート層プロトコル SCTP を使用して、TCP の代わりに SSH を実行することもできます。

歴史の歩み

反復 1

フィンランドのヘルシンキ工科大学の研究者であるタトゥ・イロネンは、所属機関のネットワークに対するパスワードスニッフィング攻撃に触発され、1995 年にプロトコルの最初のバージョン (現在では SSH-1 として知られています) を作成しました。

SSH は、rlogin、TELNET、FTP、rsh など、堅牢な認証と機密性の保証が欠けていた以前のプロトコルの役割を担うように設計されました。イロネンは自分のアプリケーションをフリーウェアとして利用できるようにしました。 1995 年 7 月、このデバイスは急速に人気が高まりました。 1995 年末までに、50 か国にまたがる 20,000 人の SSH ユーザーが存在しました。

SSH を推進し、進歩させるために、イロネンは 1995 年 12 月に SSH Communications Security を設立しました。SSH プログラムの最初のリリースでは、GNU libgmp を含むさまざまなフリー ソフトウェア コンポーネントが利用されましたが、SSH Communications Security によって提供されるその後の反復は、ますます独自のソフトウェアに成長しました。推定によると、2000 年までにユーザーは 200 万人に達しました。

反復 2

Internet Engineering Task Force (IETF) は、公式ドキュメントで SSH プロトコル バージョン 2 の作成を担当するワーキング グループを「Secsh」と指定しました。

改良されたプロトコル反復である SSH-2 は 2006 年に標準になりました。SSH-1 はこのバージョンと互換性がありません。 SSH-2 は、SSH-1 に比べて機能とセキュリティのアップグレードを提供します。たとえば、Diffie-Hellman キー交換とメッセージ認証コードによる堅牢な整合性検証により、より高いセキュリティが提供されます。単一の SSH 接続上で無制限の数のシェル セッションを操作できる機能は、SSH-2 の新機能の 1 つです。 SSH-2 は SSH-1 よりも高度で広く使用されているため、libssh (v0.8.0+)、Lsh、Dropbear などの特定の実装は SSH-2 のみをサポートします。

世界最高の自動車

反復 1.99

RFC 4253 では、バージョン 2.1 が開発されてからかなり後の 2006 年 1 月に、2.0 およびそれ以前のバージョンをサポートする SSH サーバーがそのプロトコル バージョンを 1.99 として示す必要があると規定しました。このバージョン番号は、以前のソフトウェア リビジョンを表すのではなく、下位互換性を示すために使用されます。

OSSH と OpenSSH

SSH の完全な形式

オリジナルの SSH プログラムの最後のバージョンであるバージョン 1.2.12 が 1999 年にオープンソース ライセンスの下で配布されて以来、開発者はフリー ソフトウェア バージョンの開発に取り組んできました。これは、Björn Grönvall の OSSH プログラムの基盤として使用されました。その直後、OpenBSD チームは Grönvall の成果をクローンして OpenSSH を作成し、これは OpenBSD リリース 2.6 に組み込まれました。彼らは、OpenSSH をさまざまなオペレーティング システムに移行するために、このバージョンから「移植性」ブランチを作成しました。

2005 年の時点で最も広く使用されている SSH 実装は、多くのオペレーティング システム ディストリビューションのデフォルト バージョンである OpenSSH でした。 OpenSSH 7.6 リリースのコードベースから SSH-1 サポートが削除された後も、OpenSSH は引き続き更新され、SSH-2 プロトコルをサポートします。一方、OSSH はもはや関係ありません。

用途

ユーザー「josh」は、SSH を介して X11 プログラムをトンネリングする例として、ローカル コンピューター「foofighter」から遠隔マシン「tengwar」に「SSH」接続して、xeyes を実行しました。ユーザーは Windows SSH クライアント PuTTY を利用して OpenWrt にアクセスします。

SSH は、Microsoft Windows やほとんどの Unix バリエーション (Linux、Apple の macOS を含む BSD、Solaris) を含む多くのシステムで動作するプロトコルです。次のアプリには、特定の SSH クライアントまたはサーバー専用の機能、または特定の SSH クライアントまたはサーバーと互換性のある機能が必要な場合があります。たとえば、現時点では、OpenSSH サーバーと SSH プロトコルのクライアント実装を使用して VPN を構築することのみが可能です。

  • 遠隔ホスト上のシェルにアクセスするには (Telnet と rlogin を置き換える)
  • 離れたホスト上で単独のコマンドを実行する場合 (rsh を置き換える)
  • 遠隔サーバーの自動 (パスワードなし) ログインを構成するため (たとえば、OpenSSH を使用)
  • 完全に機能する暗号化 VPN として、この機能をサポートしているのは OpenSSH クライアントとサーバーだけであることに注意してください。
  • 遠隔ホストから X を送信する場合 (複数の中間ホスト経由可能)
  • SOCKS プロトコルをサポートする SSH クライアントを使用して、暗号化されたプロキシ接続経由でインターネットを参照します。
  • SSHFS を使用して、リモート サーバーのディレクトリをファイル システムとしてローカル マシンに安全にマウントします。
  • 自動リモート サーバーの監視と管理のための上記のテクノロジの 1 つ以上を使用します。
  • SSH 互換のモバイルまたは組み込みデバイスの開発用。
  • ファイル転送メカニズムを保護するため。

ファイルの転送方法

いくつかのファイル転送システムは、次のようなセキュア シェル プロトコルを採用しています。

  • SSH 経由では、RCP プロトコルからセキュア コピー (SCP) が開発されます。
  • SCP よりも効果的であると考えられる rsync は、SSH 接続を通じて動作することがよくあります。
  • FTP の安全な代替手段は SSH ファイル転送プロトコル (SFTP) (FTP over SSH または FTPS と混同しないでください)
  • FISH (シェル プロトコルを介して転送されるファイル) は 1998 年に導入され、Unix シェル命令を介した SSH から開発されました。
  • Aspera は Fast and Secure Protocol (FASP) としても知られ、コマンドとデータ転送に SSH を使用し、UDP ポートを使用します。

建築

SSH プロトコルの階層化アーキテクチャは、次の 3 つの異なるコンポーネントで構成されています。

  • TCP/IP の伝送制御プロトコル (TCP) は、トランスポート層 (RFC 4253) で一般的に使用され、ポート番号 22 がサーバーのリスニング ポートとして確保されています。この層は、暗号化、圧縮、整合性チェック、初期キー交換、およびサーバー認証を実装します。各実装ではさらに多くのことが可能ですが、それぞれ最大 32,768 バイトの平文パケットを送受信するためのインターフェイスが上位層に公開されます。通常、1 GB のデータが転送された後、または 1 時間経過した後のいずれか早い方で、トランスポート層はキーの再交換を手配します。
    SSH の完全な形式
  • クライアント認証はユーザー認証層 (RFC 4252) を介して処理され、これもいくつかの認証技術を提供します。クライアント主導の認証とは、サーバーではなく SSH クライアントがユーザーにパスワードを要求する可能性があることを意味します。クライアントの認証要求のみがサーバーから応答を受け取ります。次のユーザー認証手法がよく使用されます。
      パスワード、パスワードを変更する機能を含む単純なパスワード認証技術。すべてのソフトウェアがこの手法を使用しているわけではありません。
  • 通常、少なくとも DSA、ECDSA、または RSA キーペアをサポートします。 公開鍵 公開鍵ベースの認証技術です。他の実装では、さらに X.509 証明書を受け入れます。
  • キーボードインタラクティブ(RFC 4256) は、サーバーが情報入力用の 1 つ以上のプロンプトを提供し、クライアントがそれらを表示し、クライアントが入力した回答を送り返す柔軟な技術です。PAM 時にパスワード認証を効果的に提供するために、一部の OpenSSH 設定で使用されます。は基盤となるホスト認証プロバイダーであるため、単純なパスワード認証技術のみをサポートするクライアントでのログインが妨げられる場合があります。
  • SSH セッションのシングル サインオン機能は、次の方法で提供されます。 GSSAPI Kerberos 5 や NTLM などの外部メカニズムを使用して SSH 認証を処理する拡張可能なシステムを提供する認証技術。 OpenSSH には機能的な GSSAPI 実装がありますが、商用 SSH 実装には企業で使用するためにこれらの技術が統合されていることがよくあります。
  • 提供される SSH サービスを定義するチャネルの概念は、接続層 (RFC 4254) によって定義されます。単一の SSH 接続から複数の SSH 接続を多重化できます。どちらもデータを双方向に送信します。チャネル要求は、サーバー側プロセスの終了コードや端末ウィンドウのサイズ変更など、特定のチャネルに特有の帯域外データを送信します。さらに、受信ウィンドウ サイズを使用して、各チャネルはそのフローを制御します。 SSH クライアントは、サーバー側ポートを転送するグローバル要求を作成します。一般的なチャネル タイプには次のものがあります。
    • SFTP、exec、および端末シェル用のシェル (SCP 転送を含む)
    • クライアントからサーバーへの転送接続用の Direct-TCPIP。
    • forwarded-tcpip を使用したサーバーからクライアントへの転送接続
    • ホストの正当性を確認するために、SSHFP DNS レコード (RFC 4255) は公開ホスト キーのフィンガープリントを提供します。

SSH はオープンな設計であるため、シェルの保護に加えて幅広いタスクに使用でき、優れた汎用性が得られます。

脆弱性

SSH-1

このプロトコル バージョンの CRC-32 によって提供されるデータ整合性保護が不十分だったため、SSH 1.5 には暗号化された SSH ストリームへの不正な挿入を可能にする脆弱性が 1998 年に確認されました。ほとんどの実装では、SSH Compensation Attack Detector として知られるパッチが追加されました。これらの改訂された実装のいくつかには、新しい整数オーバーフローの欠陥が含まれており、攻撃者がルートまたは SSH デーモンの機能を使用して任意のコードを実行できるようになります。

データ構造を試す

攻撃者が IDEA で暗号化されたセッションの最後のブロックを変更できる欠陥が 2001 年 1 月に発見されました。不正なサーバーがクライアント ログインを別のサーバーに渡すことを可能にする別の欠陥も同月に発見されました。

SSH-1 には固有の脆弱性があるため、一般に古いものとみなされており、SSH-1 フォールバックを明示的に削除して回避する必要があります。現在のほとんどのサーバーとクライアントは SSH-2 をサポートしています。

CBC の平文回復

当時の標準暗号化方式である CBC を使用して暗号化された暗号文のブロックから最大 32 ビットの平文を取得できる理論上の脆弱性が、2008 年 11 月に SSH のすべてのバージョンで発見されました。最も簡単な修正は、CTR、カウンターに切り替えることです。 CBC モードの代わりにモードを使用すると、SSH が攻撃に対して免疫になります。

SSH の完全な形式

NSAに暗号解読の疑い

2014 年 12 月 28 日にエドワード スノーデンが機密文書をシュピーゲルに公開したことは、国家安全保障局が特定の SSH 通信をデコードできる可能性があることを示唆しています。