Product SiteDocumentation Site

第9章 OpenSSH

9.1. SSH プロトコル
9.1.1. なぜ SSH を使うのか?
9.1.2. 主な機能
9.1.3. プロトコル・バージョン
9.1.4. SSH コネクションのイベント・シーケンス
9.2. OpenSSH の設定
9.2.1. 設定ファイル
9.2.2. OpenSSH サーバーの起動
9.2.3. リモート接続に対する SSH の要求
9.2.4. キー認証の使用
9.3. OpenSSH クライアント
9.3.1. ssh ユーティリティの使用方法
9.3.2. scp ユーティリティの使用方法
9.3.3. sftp ユーティリティの使用方法
9.4. 安全なシェル以上のもの
9.4.1. X11 転送
9.4.2. ポート転送
9.5. 追加のリソース
9.5.1. インストールされているドキュメント
9.5.2. 役に立つ Web サイト
SSH (Secure Shell) は、クライアント/サーバー型アーキテクチャーを用いて2つのシステム間でセキュアなコミュニケーションを促進して、ユーザーがサーバー・ホスト・システムにリモートでログインできるようにするプロトコルです。FTPTelnet のような他のリモート・コミュニケーション・プロトコルと違い、SSH はログインセッションを暗号化します。侵入者が暗号化されていないパスワードを収集するのを難しくするコミュニケーションを行います。
ssh プログラムは、telnetrsh のようなリモートホストにログインするために使用される比較的古くて比較的セキュアではないターミナル・アプリケーションを置き換えるよう設計されています。scp という関連コマンドは、rcp のようにホスト間でファイルをコピーするために設計されました。これらの比較的古いアプリケーションは、クライアントとサーバーの間で転送されるパスワードを暗号化しないので、可能な限り避けるべきです。リモートシステムにログインするために安全な方法を使用することで、クライアントシステムとリモートシステムの両方に対するリスクを減らします。
Fedora は一般的な OpenSSH パッケージ (openssh) だけでなく、OpenSSH サーバー (openssh-server) およびクライアント (openssh-clients) パッケージを含みます。OpenSSH パッケージは OpenSSL パッケージ (openssl) を必要なことに注意してください。これは OpenSSH に暗号化されたコミュニケーションを提供できるようにする、いくつかの重要な暗号ライブラリをインストールします。

9.1. SSH プロトコル

9.1.1. なぜ SSH を使うのか?

潜在的な侵入者は、システムへのアクセス権を得ようとして、ネットワークトラフィックを中断、横取り、再転送を可能にするため、自分たちの自由でさまざまなツールを持っています。一般的な言葉で、これらの脅威は以下のように分類できます:
二つのシステム間のコミュニケーションの盗聴
攻撃者は、ネットワークにおいてやりとりされる情報をすべてコピーして、コミュニケーションしている関係者の間のどこかにいることができます。
この攻撃は通常パケットスニファーを用いて実行されます。これは、ネットワークを流れる各パケットをキャプチャーして、その内容を分析する、一般的なネットワークユーティリティです。
特定のホストの詐称
攻撃者のシステムは、転送の意図した受信者のふりをするよう設定されます。この戦略がうまくいくと、ユーザーのシステムは誤ったホストとコミュニケーションしていることに気がつかないままです。
この攻撃は DNS ポイズニング と呼ばれる技術を用いて、もしくはいわゆるIP スプーフィングを経由して実行されます。前者の場合、侵入者はクライアントシステムが悪意を持って複製させたホストに向くようにクラックした DNS サーバーを使用します。後者の場合、攻撃者は信頼されたホストからであるように見える、偽造したネットワークパケットを送ります。
どちらの技術も潜在的に機密情報を傍受します。そして、もし傍受が敵対的な理由でなされるならば、壊滅的な結果になる可能性があります。SSH がリモートシェルのログインやファイルコピーのために使用されていると、これらのセキュリティの脅威を非常に減らすことができます。なぜなら、SSH クライアントとサーバーがアイデンティティを検証するために電子署名を使用するからです。加えて、クライアントとサーバーシステムの間のコミュニケーションはすべて暗号化されます。コミュニケーションのどちらのサイドもアイデンティティを偽装しても、各パケットはローカルシステムとリモートシステムのみが知っているキーを使用して暗号化されているので、うまくいきません。

9.1.2. 主な機能

SSH プロトコルは以下の安全機能を提供します:
誰も意図したサーバーのふりをできません
初期接続の後、クライアントは以前に接続していたのと同じサーバーに接続していることを確認できます。
誰も認証情報をキャプチャーできません
クライアントは、堅牢な 128-bit 暗号化を使用してサーバーへ認証情報を送信します。
誰もコミュニケーションを盗聴できません
セッション中に送信、および受信されたすべてのデータは 128-bit 暗号を使用して送信されるため、盗聴した転送データを復号および読み取ることは非常に困難になります。
加えて、以下のオプションも提供されます:
ネットワーク上でグラフィカルアプリケーションを使用する安全な手段が提供されます
X11 転送という技術を使用することで、クライアントはサーバーから X11 (X Window System) アプリケーションを転送できます。
セキュアではないプロトコルを別な方法でセキュアにする手段を提供します
SSH プロトコルは送受信されるすべてのものを暗号化します。ポート転送という技術を使用すると、SSH サーバーは、POP のようなセキュアではないプロトコルを別な方法でセキュアにして、全体のシステムとデータのセキュリティを向上させる、トンネルになります。
セキュアなチャネルを作成するために使用できます
OpenSSH のサーバーとクライアントは、それらのマシンの間でトラフィックに対して VPN のようなトンネルを作成するよう設定できます。
Kerberos 認証をサポートします
OpenSSH のサーバーおよびクライアントは、Kerberos ネットワーク認証プロトコルの GSSAPI (Generic Security Services Application Program Interface) 実装を用いて認証するよう設定できます。

9.1.3. プロトコル・バージョン

現在 SSH には2種類あります。バージョン1と新しいバージョン2です。Fedora の OpenSSH は SSH バージョン2を使用します。これは、バージョン1において知られていたエクスプロイトに脆弱性がない、改善された鍵交換アルゴリズムを持ちます。しかしながら、互換性のため、OpenSSH はバージョン1の接続も同様にサポートします。

SSH バージョン 1 の使用を避ける

接続に対する最大限のセキュリティを確実にするには、SSH バージョン2対応のサーバーとクライアントのみが可能な限り使用することが推奨されます。

9.1.4. SSH コネクションのイベント・シーケンス

以下の連続したイベントは、2つのホスト間の SSH 通信の統合性を保護するのに役に立ちます。
  1. 暗号方式ハンドシェークが行なわれ、クライアントは正しいサーバーと交信していることを確認します。
  2. クライアントとリモートホスト間接続のトランスポートレイヤーは対象型暗号を使用して暗号化されます。
  3. クライアントはサーバーに対して自身を認証します。
  4. リモートクライアントは、暗号化した接続を通じてリモートホストと交信します。

9.1.4.1. トランスポート層

トランスポートレイヤーの主な役割は認証時とその後の通信期間での2つのホスト間に於ける安全な交信を用意することです。トランスポートレイヤーは、データの暗号化と複合化すること、そして、データが送信と受信される時にデータパケットの統合性を保護することで、この役割を達成します。トランスポートレイヤーはまた、情報を圧縮して送信の高速化もします。
SSH クライアントがサーバーに接続すると、基本情報が交換されて両システムは正しくトランスポートレイヤーを構築することができるようになります。この交換の間に以下のようなステップが起こります:
  • 鍵が交換されます
  • 公開鍵暗号化アルゴリズムが決定されます
  • 対象型暗号化アルゴリズムが決定されます
  • メッセージ認証アルゴリズムが決定されます
  • ハッシュアルゴリズムが決定されます
鍵交換の間、サーバーはそれ自身を独自の ホスト鍵 で、クライアントに対して証明します。クライアントがこの特定のサーバーと過去に通信したことがなければ、サーバーのホスト鍵はクライアントには未知であり、接続は成立しません。 OpenSSH は、サーバーのホスト鍵を承認することでこの問題を回避します。これは、ユーザーが通知を受けて新規のホスト鍵を承認し確証した後に起こります。それ以降の接続では、サーバーのホスト鍵は、クライアント上に保存してある情報と照らし合わせてチェックされ、クライアントが本当に目的のサーバーと通信していることの確証を与えます。時間が経過して、このホスト鍵が一致しない状態が起こると、ユーザーがクライアントに保存してある古い情報を削除することにより、新しい接続が可能になります。

常に新しい SSH サーバーの完全性を検証する

ローカルシステムは本来のサーバーと攻撃者が設定した偽のサーバーとの違いを理解しない為、攻撃者は初期交信の時点で SSH サーバーとして擬装することが可能になります。この防止への手助けとして、最初の接続の前に、又はホスト鍵の不一致が発生した場合にサーバー管理者へ連絡することで、新規の SSH サーバーの統合性を確認すると良いでしょう。
SSH はほとんど全ての公開鍵アルゴリズム、又はエンコード形式で機能するように設計されています。初期の鍵交換が、秘密値の交換と共有に使用されるハッシュ値を作成した後、2つのシステムは迅速に新しい鍵とアルゴリズムを算出してこの接続で送信される認証と将来のデータを保護します。
設定された鍵とアルゴリズムを使用して一定量のデータが送信された後 (この量は SSH の実装によりことなります)、別の鍵交換が発生してもう1つのハッシュ値セットと新しい共有秘密値が生成されます。攻撃者がハッシュ値と共有秘密値を判別できたとしても、その情報はほんの短い時間しか役に立ちません。

9.1.4.2. 認証

トランスポートレイヤーが安全なトンネルを構築して2つのシステム間で情報が渡されると、サーバーはクライアントに対して、秘密鍵のエンコードを持つ署名やパスワード入力の使用などサポートされている別の認証方法を伝えます。クライアントはその後、これらのサポートのある方法でサーバーに対して自身の認証を試みます。
SSH サーバーとクライアントは異なるタイプの認証方法を許可できるように設定されており、これが両側に高水準の制御を与えます。サーバーはそのセキュリティモデルに応じて、サポートする暗号化方法を決定することができ、クライアントは利用できるオプションの中から認証方法の順番を選択することができます。

9.1.4.3. チャネル

SSH 転送層において認証が成功した後、複数のチャネルが多重化[2]という技術により開かれます。これらのチャネルはそれぞれ異なるターミナルセッションとX11転送セッションのコミュニケーションを取り扱います。
クライアントとサーバーの両方は新規のチャンネルを作成することができます。各チャンネルはその後、接続の両端で別々の番号が割り当てられます。クライアントが新規のチャンネルを開こうと試みる時、クライアントは要求と一緒にチャンネル番号を送信します。この情報はサーバーで保存され、そのチャンネルに通信を転送するのに使用されます。これは、異なるタイプのセッションがお互いに干渉しないようにするため、及び、あるセッションが終了した時にそのチャンネルが主要 SSH 接続を妨害せずに閉じることができるようにするためです。
チャンネルは、 flow-control もサポートしており、これはチャンネルが順序良くデータを送信/受信するのを可能にします。この方法では、クライアントがチャンネルが開いていると言うメッセージを受信するまで、データはチャンネルに送信されません。
クライアントが要求するサービスのタイプとユーザーがネットワークに接続されている方法に従って、クライアントとサーバーは、自動的に各チャンネルの構成を折衝します。これにより、プロトコルの基本構成を変更することなく、異なるタイプのリモート接続の処理に多大な柔軟性を得ることができます。


[2] 多重化された接続は共有された一般的なメディア上で送られる複数の信号から構成されます。SSH では、異なるチャネルが共通のセキュアなコネクション上で送られます。