Show Table of Contents
第12章 OpenSSH
SSH (Secure Shell: セキュアシェル) は、クライアント/サーバーアーキテクチャーを使用する 2 つのシステム間でのセキュアな通信を容易にし、ユーザーがリモートでサーバーホストシステムにログインできるようにするプロトコルです。FTP や Telnet などの他のリモート通信プロトコルとは異なり、SSH はログインセッションを暗号化するため、侵入者が暗号化されていないパスワードを入手するための接続が難しくなります。
ssh プログラムは、
telnet や rsh などのリモートホストへのログインに使用される旧式でセキュリティーの低いターミナルアプリケーションに代わるものとして設計されています。また、scp と呼ばれる関連プログラムが、ホスト間でファイルをコピーするために設計された rcp のような旧式プログラムの代わりとなります。これら旧式アプリケーションはクライアントとサーバー間で送信するパスワードを暗号化しないので、可能な限り使用を避けるようにしてください。リモートシステムへのログインにセキュアな方法を使用することで、クライアントシステムとリモートホストの両方に対するリスクが低減されます。
Red Hat Enterprise Linux には、一般的な OpenSSH パッケージ (openssh) と共に、OpenSSH サーバー (openssh-server) およびクライアント (openssh-clients) パッケージが含まれています。OpenSSH パッケージでは、いくつかの重要な暗号化ライブラリーをインストールし、OpenSSH の暗号化通信を可能にする OpenSSL パッケージ (openssl-libs) が必要になる点に注意してください。
12.1. SSH プロトコル
12.1.1. SSH を使用する理由
潜在的な侵入者は、ネットワークトラフィックの中断、傍受、経路変更を可能にする様々なツールを自由に駆使して、システムに侵入します。一般的には、これらの脅威は以下のとおり分類できます。
- 2 システム間の通信の傍受
- 攻撃者は、ネットワーク上で通信を行う二者の間のどこかに潜み、両者間で渡される情報をコピーしている可能性があります。攻撃者は情報を傍受して保持する、または情報を改ざんして対象となる受信者に送信する場合があります。このような攻撃は、通常 パケットスニファ を使用して行われます。パケットスニファは、ネットワークを通過するパケットをキャプチャしてその内容を分析するかなり一般的なネットワークユーティリティーです。
- 特定のホストの偽装
- 攻撃者のシステムは、送信の対象となる受信者を装うように設定されます。この戦略が成功すると、ユーザーのシステムは不正なホストと通信していることに気がつかないままとなります。この攻撃は、DNS ポイズニング として知られる手法か IP スプーフィング と呼ばれる手法を用いて実行されます。前者の場合、侵入者はクラックされた DNS サーバーを使用して、クライアントシステムを不当に複製されたホストへポイントします。後者の場合は、侵入者は信頼されたホストから送信されたように見せかけた偽装ネットワークパケットを送信します。
いずれの手法でも、潜在的な機密情報を傍受することが可能です。その傍受が悪意のある理由で行われる場合には、悲惨な結果をもたらしかねません。リモートシェルログインとファイルコピー用に SSH を使用すると、こうしたセキュリティー脅威を大幅に軽減することができます。これは、SSH クライアントとサーバーがデジタル署名を使用してそれぞれの ID を確認するためです。さらに、クライアントシステムとサーバーシステム間の全通信は暗号化されます。各パケットはローカルシステムとリモートシステムのみに知られている鍵を使用して暗号化されるため、通信のいずれか一方の ID をスプーフィングする試みは成功しません。
12.1.2. 主な機能
SSH プロトコルは、以下のような保護手段を提供します。
- 対象のサーバーとして装うことができません
- 初回接続後に、クライアントは以前に接続したサーバーと同じサーバーに接続していることを確認できます。
- 認証情報の取得はできません
- クライアントは、強力な 128 ビット暗号化を使用してサーバーへ認証情報を送信します。
- 通信の傍受はできません
- セッション中に送受信された全データは、128 ビット暗号化を使用して転送されるため、傍受された送信データの暗号解読と読み取りは非常に困難になります。
さらに、SSH プロトコルは以下のようなオプションも提供します。
- ネットワーク上でグラフィカルアプリケーションを使用するセキュアな手段を提供します
- クライアントは、X11 転送 と呼ばれる手法を使用して、サーバーから X11 (X Window System) アプリケーションを転送することが可能です。
- セキュアでないプロトコルをセキュアにする手段を提供します
- SSH プロトコルは、送受信するものすべてを暗号化します。SSH サーバーは、ポート転送 と呼ばれる手法を使用して、POP のようなセキュアでないプロトコルをセキュアにするための経路となり、システムとデータ全体のセキュリティーを強化することができます。
- セキュアなチャンネルを作成できます
- OpenSSH サーバーとクライアントは、サーバーとクライアントマシン間のトラフィックに対し仮想プライベートネットワークに似たトンネルを作成するよう設定できます。
- Kerberos 認証に対応します
- OpenSSH のサーバーとクライアントは、Kerberos ネットワーク認証プロトコルの GSSAPI (Generic Security Services Application Program Interface: 汎用セキュリティサービス API) 実装を使用して認証を行うよう設定できます。
12.1.3. プロトコルのバージョン
現在、SSH には バージョン 1 とバージョン 2 (新規) の 2 つの種類があります。Red Hat Enterprise Linux 7 の OpenSSH スイートでは、SSH バージョン 2 を使用します。バージョン 2 は、バージョン 1 での既知のエクスプロイトに対して脆弱性のない拡張された鍵交換アルゴリズムを使用します。Red Hat Enterprise Linux 7 では、OpenSSH スイートはバージョン 1 の接続に対応していません。
12.1.4. SSH 接続のイベントシーケンス
以下に挙げる一連のイベントは、2 つのホスト間で行われる SSH 通信の整合性を保護するために役立ちます。
- 暗号化ハンドシェイクが行われ、クライアントは正しいサーバーと通信していることを確認できます。
- クライアントとリモートホスト間の接続のトランスポート層は、対称暗号方式を使用して暗号化されます。
- クライアントはサーバーに対して自己認証します。
- クライアントは、暗号化された接続でリモートホストと対話します。
12.1.4.1. トランスポート層
トランスポート層の主な役割は、認証時およびその後の通信中における 2 つのホスト間の安全でセキュアな通信を容易にすることです。トランスポート層は、データの暗号化と復号化を処理し、データパケットの送受信時にその整合性を保護することでその役割を果たします。また、トランスポート層は、情報を圧縮して転送を高速化します。
SSH クライアントがサーバーにコンタクトすると、基本情報が交換されるため両システムはトランスポート層を適正に構築することができます。以下は、こうした基本情報の交換中に発生するステップです。
- 鍵が交換される。
- 公開鍵暗号化アルゴリズムが決定される。
- 対称暗号化アルゴリズムが決定される。
- メッセージ認証アルゴリズムが決定される。
- ハッシュアルゴリズムが決定される。
鍵交換の間、サーバーは一意の ホスト鍵 を用いて、クライアントに対して自己識別を行います。クライアントがこの特定のサーバーと過去に通信したことがなければ、サーバーのホスト鍵はクライアントには未知であり、接続は成立しません。OpenSSH はこの問題に対処するためにサーバーのホスト鍵を承認します。これは、ユーザーが通知を受けて新規のホスト鍵を受け取り検証した後に行われます。それ以降の接続では、サーバーのホスト鍵は、クライアント上に保存されているバージョンと照合され、クライアントが実際に目的のサーバーと通信していることを確信できます。この後に、ホスト鍵が一致しなくなった場合には、ユーザーは接続前にクライアントの保存してあるバージョンを削除する必要があります。
警告
ローカルシステムは、対象サーバーと攻撃者が設定した偽サーバーとの違いを認識しないため、攻撃者は初回コンタクト中に SSH サーバーをマスカレードすることが可能です。この問題を防ぐために、初回接続の前かホスト鍵の不一致が発生した場合には、サーバー管理者へ連絡して新しい SSH サーバーの整合性を確認してください。
SSH は、ほとんどすべての公開鍵アルゴリズムまたはエンコード形式に対応するように設計されています。初回の鍵交換で、交換に使用されるハッシュ値と共有秘密値が作成された後、2 つのシステムは新しい鍵とアルゴリズムの計算を直ちに開始して、認証と今後この接続で送信されるデータを保護します。
所定の鍵とアルゴリズムを使用して一定量のデータ (正確な量は SSH 実装により異なる) が送信された後に、もう 1 回鍵交換が行われてハッシュ値と新しい共有秘密値の別のセットが生成されます。攻撃者がハッシュ値と共有秘密値を判別できたとしても、その情報が役に立つのは限られた時間のみです。
12.1.4.2. 認証
トランスポート層が 2 つのシステム間で情報を渡すためのセキュアなトンネルを構築すると 、サーバーは秘密鍵でエンコードされた署名の使用やパスワードの入力など、サポートされている別の認証方法をクライアントに伝えます。次に、クライアントはサポートされているいずれかの方法を使ってサーバーに対して自己認証を試みます。
SSH サーバーとクライアントは、異なるタイプの認証を採用できるように設定可能なため、双方の制御が最適化されます。サーバーはそのセキュリティーモデルに基づき、サポートする暗号化方法を決定することができ、クライアントは利用可能なオプションの中から試行する認証方法の順番を選択できます。
12.1.4.3. チャンネル
SSH トランスポート層での認証に成功した後は、多重化[1] と呼ばれる手法により複数のチャンネルが開かれます。これらの各チャンネルは、異なるターミナルセッションと転送された X11 セッションの通信を処理します。
クライアントとサーバーの両方で、新しいチャンネルを作成できます。その後、各チャンネルに別々の番号が接続の両端に割り当てられます。クライアントが新しいチャンネルを開こうとする時には、クライアントは要求と共にチャンネル番号を送信します。この情報はサーバーにより保存され、そのチャンネルに通信を移動するために使用されます。これは、異なるタイプのセッションが相互に影響しないように、あるセッションの終了時にそのチャンネルが SSH による一次接続を停止せずに閉じることができるようにするためです。
また、チャンネルは フロー制御 もサポートしているため規則的な方法でデータを送受信することができます。この方法では、チャンネルが開いているというメッセージをクライアントが受信するまで、データはチャンネル上で送信されません。
クライアントが要求するサービスのタイプとユーザーがネットワークに接続される方法に応じて、クライアントとサーバーは、各チャンネルの特性を自動的にネゴシエートします。これにより、プロトコルの基本インフラストラクチャーを変更しなくても、異なるタイプのリモート接続を非常に柔軟に処理することができます。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.