9.2. リモートログイン

管理者にとってコンピュータにリモートから接続できることは不可欠な要素です。専用の部屋に閉じ込められているサーバにキーボードとモニタが常設されていることはめったにありません。しかしサーバはネットワークにつながっています。

9.2.1. 安全なリモートログイン、SSH

SSH (Secure SHell) プロトコルは安全性と信頼性を念頭に置いて設計されました。SSH を使う接続は安全です。つまり、通信相手は認証され、交換されるデータはすべて暗号化されます。

VOCABULARY 認証、暗号化

クライアントに対してサーバ上で作業を実行したり作業を自動的に開始したりすることを許可する必要がある場合、安全性が重要です。クライアントは必ず本人であることを確認されなければいけません。これが認証です。通常、本人確認はパスワードを使って行います。パスワードは人目に触れさせてはいけません。そうでなければ、他のクライアントがパスワードを取得できてしまうからです。これが暗号化の目的です。暗号化は符号化の形をしています。暗号化することで、2 つのシステムが公衆回線を使って秘密の情報を他人に読まれないように保護した状態でやり取りすることが可能になります。

認証と暗号化はしばしば一緒に言及されます。なぜなら両者は同時に使われることが多く、よく似た数学的概念を基に実行されることが多いからです。

さらに SSH は 2 種類のファイル転送サービスを提供します。scp は cp のように使えるコマンドラインツールです。ただし、他のマシンへのパスを表記するにはパスの前にそのマシンの名前とコロンを付ける点が cp と異なります。

$ scp file machine:/tmp/

sftp は対話型コマンドで ftp に似ています。sftp は単一のセッションの中で複数のファイルを転送したり、リモートのファイルを操作 (削除、リネーム、パーミッション変更など) したりすることが可能です。

Debian は OpenSSH を使います。OpenSSH は SSH のフリーソフトウェア版で OpenBSD (BSD カーネルに基づき、安全性を重要視する自由なオペレーティングシステム) プロジェクトによってメンテナンスされており、フィンランドの SSH Communications Security Corp が開発した元祖 SSH ソフトウェアのフォークです。SSH Communications Security Corp は当初 SSH をフリーソフトウェアとして開発していましたが、結局プロプライエタリライセンスで開発を続けることを決定しました。そして OpenBSD プロジェクトが SSH のフリーソフトウェア版としてメンテナンスするために OpenSSH を作成しました。

BACK TO BASICS フォーク

ソフトウェアの分野で「フォーク」とは、既存のプロジェクトのクローンとして始まった新しいプロジェクトを意味しており、既存のプロジェクトの対抗馬です。通常、両方のソフトウェアは新しい開発という観点ですぐに別のものになっていきます。フォークは開発チーム内の意見の不一致によって起こることが多いです。

プロジェクトをフォークするという選択肢はフリーソフトウェアの本質そのものから生じた直接的な結果です。フリーソフトウェアとしてのプロジェクトの存続を可能にするための (たとえばライセンスが変更された場合などの) フォークは健全な出来事です。技術的および個人的な意見の不一致によって起こるフォークは通常人的資源の無駄です。従って別の解決策が望まれます。過去にフォークした 2 つのプロジェクトの合併はいまだ前例がありません。

OpenSSH は 2 つのパッケージに分割されています。すなわち、クライアント部分は openssh-client パッケージ、サーバ部分は openssh-server パッケージに分割されています。ssh メタパッケージは両方のパッケージに依存しており、これを使えば両方のインストールが簡単になります (apt install ssh だけでクライアントとサーバの両方がインストールされます)。

9.2.1.1. 鍵認証方式

リモートサーバはユーザを認証するために SSH でログインする人に対して毎回パスワードを尋ねます。これは、接続を自動化したい場合や SSH 経由で頻繁に接続を行うツールを使う場合に問題です。このため、SSH は鍵認証システムを提供しています。

ユーザはクライアントマシンで ssh-keygen -t rsa を使って鍵ペアを生成します。この時公開鍵は ~/.ssh/id_rsa.pub に保存され、一方で公開鍵に対応する秘密鍵は ~/.ssh/id_rsa に保存されます。その後ユーザは ssh-copy-id server を使って、自分の公開鍵をサーバの ~/.ssh/authorized_keys ファイルに追加登録します。秘密鍵を生成した際に「パスフレーズ」で保護しなかった場合、公開鍵を登録したサーバに対する以降すべてのログインでパスワードは不要です。そうでなければ、秘密鍵を使う際は毎回パスフレーズを入力して秘密鍵を復号化しなければいけません。幸いにも、ssh-agent を使えば復号化された秘密鍵がメモリ内に保存され、パスワードをきちんと再入力する必要がなくなります。これを実現するには、セッションが既に機能する ssh-agent のインスタンスに関連付けられている条件下で、単純に (作業セッションごとに 1 回) ssh-add を使ってください。Debian はグラフィカルセッションではデフォルトで ssh-agent を有効化しますが、/etc/X11/Xsession.options を変更すれば無効化することも可能です。コンソールセッションでは手作業で eval $(ssh-agent) を実行することで ssh-agent を開始できます。

SECURITY 秘密鍵の保護

秘密鍵を持っていれば、誰でも対応する公開鍵を登録したアカウントにログインすることが可能です。このため、秘密鍵の利用は「パスフレーズ」で保護されています。秘密鍵ファイル (たとえば ~/.ssh/id_rsa) のコピーを不正に入手した人が秘密鍵を使うためには、パスフレーズを知らなければいけません。しかしながら、「パスフレーズ」による追加的な保護は堅固なものではありません。秘密鍵ファイルが不正に使われていると感じたなら、その秘密鍵に対応する公開鍵をインストールしたコンピュータでその公開鍵の使用を停止し (authorized_keys ファイルから公開鍵を削除し)、新しく生成した鍵で公開鍵を置き換えるのが最良の対応策です。

CULTURE Debian Etch における OpenSSL の脆弱性

当初 Debian Etch から配布されていた OpenSSL ライブラリは乱数発生器 (RNG) に深刻な問題がありました。はっきり言うと、Debian メンテナによって valgrind などのメモリテストツールで OpenSSL ライブラリを使うアプリケーションを解析した際に警告を出さなくなるような変更が行われました。不幸なことに、この変更により RNG はエントロピーソースを 1 つしか使わなくなりました。ここで使われたエントロピーソースはプロセス ID (PID) に相当するもので、PID の取りうる値は 32,000 程度しかないため PID をソースとして用いたことにより十分な乱数度が得られなくなりました。

→ http://www.debian.org/security/2008/dsa-1571

具体的に言えば、OpenSSL を使って鍵を生成した場合、生成された鍵は常に数十万 (鍵長種数の 32,000 倍) の既知の範囲内にある鍵のうちの 1 つになります。この脆弱性は、たとえば OpenVPN など数多くのアプリケーションが使う SSH 鍵、SSL 鍵、X.509 証明書に影響をおよぼしました。クラッカーは全種類の鍵を試すだけで不正アクセスを実行することが可能でした。この問題の影響を減らす目的で、SSH デーモンは openssh-blacklist と openssh-blacklist-extra パッケージにリストされている問題のある鍵を拒否するように変更されました。さらに、ssh-vulnkey コマンドを使えば、システム内からこの脆弱性の影響を受けているかもしれない鍵を識別することが可能です。

この出来事をいっそう詳しく調べると、これは OpenSSL プロジェクト内と Debian パッケージメンテナ双方にあった多数の (小さな) 問題の結果であるということが、明らかになります。OpenSSL のように広く使われるライブラリは (修正せずとも) valgrind でテストした時に警告を出すべきではありません。さらに、コード (特に RNG と同様に慎重に取り扱われるべき部分) はこのような誤解を避ける目的で詳しい注釈を付けられるべきです。Debian 側について言えば、メンテナは OpenSSL 開発者から修正に対する検証を受けることを望んでいながら、修正の検証に必要なパッチを OpenSSL 開発者に提供することもせずに自分の修正について簡単に説明しただけで、Debian 内における自分の役割を口にすることもしませんでした。そして最後に、メンテナンス方針が最適なものではありませんでした。具体的に言えば、元のコードに対して行った修正が文書中で明らかにされず、さらにすべての修正は Subversion リポジトリに効果的に保存されていましたが、最終的にすべての修正はソースパッケージの作成中に 1 つのパッチにまとめられていました。

このような状況下では、これと同様の出来事が繰り返されることを避けるための適切な矯正措置を見つけるのは難しいです。ここで覚えておくべき教訓は Debian が上流開発ソフトウェアに対して導入したすべての変更は正当化され、文書化され、可能であれば上流プロジェクトに提出され、広く公開されなければいけないということです。この視点から、新しいソースパッケージフォーマット (「3.0 (quilt)」) と Debian ソースウェブサービスが開発されました。

→ http://sources.debian.org

9.2.1.2. リモートの X11 アプリケーションを使う

SSH プロトコルを使うと、グラフィカルデータ (「X11」セッション、Unix で最も広く使われているグラフィカルシステム) を転送することが可能です。サーバはこれらのデータ専用の経路を開いたままにします。具体的に言うと、リモートで実行されたグラフィカルプログラムはローカル画面の X.org サーバ上に表示され、すべてのセッション (入力と表示) は保護されます。X11 転送機能によりリモートアプリケーションがローカルシステムに干渉することになるため、X11 転送機能はデフォルトで無効化されています。X11 転送機能を有効化するには、SSH サーバの設定ファイル (/etc/ssh/sshd_config) で X11Forwarding yes と指定してください。さらにユーザは ssh コマンドラインに -X オプションを追加して転送を要求しなければいけません。

9.2.1.3. ポート転送を使った暗号化トンネルの作成

ssh の -R と -L オプションを使うと、ssh が 2 台のマシン間で「暗号化トンネル」を作成することが可能です。「暗号化トンネル」を使えば、ローカル TCP ポート (補注「BACK TO BASICS TCP/UDP」を参照してください) をリモートのマシンに安全に転送したりその逆を行うことも可能です。

VOCABULARY トンネル

インターネットとインターネットに接続されている多くの LAN はパケットモードで動作しており、接続モードで動作していません。これは、一方のコンピュータから他方のコンピュータに向かって送信されたパケットは、宛先への経路を見つけるために複数の中間ルータで足止めされることを意味しています。とは言っても、接続モードを模倣することも可能です。接続モードではストリームを普通の IP パケットの中にカプセル化します。これらのパケットは通常の経路を通過しますが、ストリームは宛先を変えられることなく再構成されます。これは道路のトンネルにかけて「トンネル」と呼ばれています。道路のトンネルでは車両が入口 (入力) から出口 (出力) まで交差点に遭遇することなくまっすぐ進むのに対し、地上の経路を使うと車両は交差点を通過したり右折左折を繰り返しながら目的地まで進むことになります。

トンネルに暗号化機能を追加することが可能です。すなわち、トンネルの中を流れるストリームは外から認識できませんが、トンネルの出口で復号化された形で返されます。

ssh -L 8000:server:25 intermediary を使うことで、ローカルの ssh に intermediary との SSH セッションを確立させ、ローカルの ssh にローカルのポート 8000 番をリッスンさせます (図 9.3「SSH を使ったローカルポートの転送」を参照してください)。ローカルのポート 8000 番を経由して接続が開始されたら、intermediary の ssh は intermediary から server のポート 25 番に接続し、ローカルから server への接続を中継します。

ssh -R 8000:server:25 intermediary を使うことで、ローカルの ssh に intermediary との SSH セッションを確立させ、intermediary の ssh に intermediary のポート 8000 番をリッスンさせます (図 9.4「SSH を使ったリモートポートの転送」を参照してください)。intermediary のポート 8000 番を経由して接続が開始されたら、ローカルの ssh はローカルから server のポート 25 番に接続し、intermediary から server への接続を中継します。

どちらの場合も、ローカルと intermediary の間に確立した SSH トンネルを介して、server のポート 25 番に接続します。最初の例の場合、トンネルの入口はローカルのポート 8000 番で、データはまず intermediary を目指し、その後に「公開」ネットワークを経由して server に向かいます。2 番目の例の場合、トンネルの入口と出口が逆になります。トンネルの入口は intermediary のポート 8000 番で、出口はローカルにあります。出口から出たデータは server に向かいます。現実的な話をすると、ここで使われている server にはローカルまたは intermediary を指定することが多いです。このようにして SSH は端から端までの接続を保護します。

図 9.3 SSH を使ったローカルポートの転送

図 9.4 SSH を使ったリモートポートの転送

9.2.2. リモートグラフィカルデスクトップの利用

VNC (Virtual Network Computing) を使うとグラフィカルデスクトップにリモートからアクセスすることが可能になります。

VNC は技術支援に使われることが多いです。なぜなら、管理者はユーザが直面しているエラーを見ることが可能で、ユーザの側にいなくても正しい行動の仕方をユーザに示すことが可能だからです。

リモートデスクトップを使うには、最初にユーザが自分のセッションを共有することを認可しなければいけません。Jessie に含まれる GNOME グラフィカルデスクトップ環境の場合、設定パネル内にこれを行うオプションが含まれています (以前の Debian のバージョンではユーザが vino をインストールして実行しなければいけませんでした)。KDE Plasma の場合、既存のセッションを VNC を介して共有するには krfb を使う必要があります。他のグラフィカルデスクトップ環境の場合、x11vnc コマンド (同名の Debian パッケージに含まれます) を使います。さらに、管理者はわかりやすいアイコンを作ってユーザが x11vnc を実行できるようにすることが可能です。

VNC がグラフィカルセッションを利用できるようにしたら、管理者は VNC クライアントでセッションに接続しなければいけません。VNC クライアントとして、GNOME には vinagre と remmina が用意されており、KDE プロジェクトは krdc (K → インターネット → リモートデスクトップクライアント) を開発しています。コマンドラインを使う他の VNC クライアントもあります。たとえば、xvnc4viewer (同名の Debian パッケージに含まれます) などです。ひとたびセッションに接続したら、管理者は何が起きているか確認し、リモートでマシンの作業を行い、ユーザにその様子を見せることが可能です。

SECURITY VNC over SSH

VNC で接続したいけれども、データを平文でネットワークに流したくない場合、SSH トンネルでデータをカプセル化することが可能です (第 9.2.1.3 節「ポート転送を使った暗号化トンネルの作成」を参照してください)。この時知っておかなければいけない点は、デフォルトで VNC は最初の画面 (「localhost:0」と呼ばれます) にポート 5900 番、2 番目の画面 (「localhost:1」と呼ばれます) にポート 5901 番を使うという点だけです。

ssh -L localhost:5901:localhost:5900 -N -T machine コマンドを使うことで、localhost インターフェースのポート 5901 番と machine のポート 5900 番の間にトンネルが作られます。最初の「localhost」はローカルのインターフェースのみをリッスンするように SSH を制限します。2 番目の「localhost」は「localhost:5901」に入ってきたネットワークトラフィックを受け取るリモート側のインターフェースを表します。そんなわけで、vncviewer localhost:1 はローカルの名前を使っているにも関わらず VNC クライアントをリモートの画面に接続します。

VNC セッションを閉じたら、対応する SSH セッションを終了してトンネルを閉じることも忘れないでください。

また、モバイルユーザや会社幹部のような自分が仕事場で使っているのとよく似たリモートデスクトップにアクセスするために時々自宅からログインする必要があるユーザにとって、VNC は都合の良いものです。そのようなサービス用の設定はより複雑です。具体的に言えば、管理者は最初に vnc4server パッケージをインストールし、XDMCP Query 要求を受け入れるようにディスプレイマネージャの設定を変更し (gdm3 の場合、/etc/gdm3/daemon.conf の「xdmcp」セクションに Enable=true を追加し)、そして最後に inetd を使って VNC サーバを起動するように設定します。こうすることで、ユーザがログインを試行したらセッションが自動的に開始されるようになります。たとえば、以下の行を /etc/inetd.conf に追加します。

5950  stream  tcp  nowait  nobody.tty  /usr/bin/Xvnc Xvnc -inetd -query localhost -once -geometry 1024x768 -depth 16 securitytypes=none

入ってくる接続をディスプレイマネージャに転送することにより、認証の問題が解決されます。なぜなら、ローカルアカウントを持つユーザだけが gdm3 (または同等の kdm、xdm など) のログイン画面を突破できるからです。このやり方は (サーバの性能が十分高いなら) なんの問題もなく複数の同時ログインを許すため、完全なデスクトップをモバイルユーザに対して (またはシンクライアントとして設定された非力なデスクトップシステムに対して) 提供するという用途にも応用できます。ユーザは単純に vncviewer server:50 でサーバの画面にログインするだけです。なぜなら、使われているポートは 5950 番だからです。