目次


VNC でマルチユーザー・ログインを可能にする

ユーザーがどこからでもマルチユーザー Linux システムにアクセスできるようにする

Comments

VNC サーバーおよび X サーバーのアーキテクチャー

Linux では、グラフィカル・ユーザー・インターフェース (GUI) として X Window System (略して X) が使用されます。X はいくつかの点で独特な GUI です。その独特な点の 1 つは、本質的にネットワーク対応であることです。X サーバーは文字通り、ネットワーク・サーバー・プログラムです。ネットワーク・サーバー・プログラムは、クライアント・プログラムに対してローカル・リソースへのアクセスを提供しますが、このことは X サーバーにも当てはまります。ただし、通常とは異なり、X サーバーで言う「ローカル・リソース」とは、ユーザーが使用するディスプレイ、キーボード、マウスのことです。最も一般的な構成では、X クライアント・プログラムは X サーバーと同じコンピューター上で実行されます。したがって、LibreOffice やGIMP (GNU Image Manipulation Program) などの X クライアント・プログラムは、X サーバーと同じコンピューター上で X のネットワーク・プロトコルを使用してユーザー入力を受け取り、ユーザーに対して出力を表示します。

一方で、ネットワーク経由で X を使用する場合には、ユーザーは X サーバー・コンピューターを操作し、ユーザーが実行したい X クライアント・プログラムは、別のコンピューター上で実行されます。この場合の構成には、接続を開始する 2 つ目のネットワーク・プロトコルが必要です。その 2 つ目のプロトコルとしては、telnet、SSH (Secure Shell)、または XDMCP (X Display Manager Control Protocol) を使用することができます。このログイン・プロトコルのサーバーは X クライアント・コンピューター上で動作し、リモート・ログイン・クライアントは X サーバー・コンピューター上で動作します。リモート・ログイン・サーバーが X クライアントを起動すると、X クライアントが X サーバーに接続するという仕組みです。図 1 に、この関係を示します。破線矢印は、セッションの開始を示します (XDMCP が使用される場合、XDMCP クライアントは X サーバー・プログラムに組み込まれます)。

図 1. X リモート・アクセスには、両方のコンピューター上にクライアントとサーバーが必要です
X クライアントと X サーバーの関係を示す図
X クライアントと X サーバーの関係を示す図

このような構成は多くのローカル・ネットワーク上で問題なく機能するものの、そこには欠点があります。例えば、この構成ではネットワーク・プロトコルを X サーバー・コンピューター側からも X クライアント・コンピューター側からも開始する必要がありますが、ファイアウォールや NAT (Network Address Translation: ネットワーク・アドレス変換) ルーターがあるためにネットワーク・プロトコルを開始できない場合も考えられます (SSH を使用する場合、X セッションのトンネリングが可能なので、こうした問題に対処する必要がなくなります)。さらに、X サーバーはほとんどのプラットフォームで使用できますが、一般に Windows を実行するコンピューターにインストールされることはありません。このような理由から、多くのサイトでは別のプロトコルとして、RFB (Remote Frame Buffer) が使用されています。RFB は、VNC (Virtual Network Computing) プログラム・ファミリーに実装されているプロトコルです。

VNC は、あらゆるタイプのクライアントから Linux、UNIX、Mac OS X、Windows およびその他のシステムへのリモート・アクセスを可能にするクロスプラットフォーム・ツールです。VNC の場合、ユーザーはクライアント・コンピューターを操作して、リモート・サーバー・コンピューターにアクセスします。Linux での VNC サーバーは、ローカル X サーバーの画面の内容をリモート・コンピューターに表示させるか、ローカル画面を管理する X サーバーとは独立して動作できる、VNC サーバー固有の X サーバーを組み込むか、このいずれかを行います。この構成は、図 2 に示すようになります。この図でも同じく、破線矢印はセッションの開始を表します。この構成では、VNC クライアント・コンピューター側からのネットワーク接続は必要ですが、VNC サーバー・コンピューター側からの接続は不要になります。さらに、VNC クライアントおよび VNC サーバーはさまざまなオペレーティング・システムに対応するため、ユーザーは 1 つのクライアント・プログラムだけで任意のサーバーにアクセスすることができます。

図 2. VNC サーバーはローカル X クライアント・プログラムと通信可能な X サーバーを組み込みます
VNC サーバーが X サーバーの内容をクライアントに送信する方法を示す図
VNC サーバーが X サーバーの内容をクライアントに送信する方法を示す図

VNC の欠点は、RFB 認証がパスワードのみによって行われ、ユーザー名は使用されないことです。そのため、それぞれのユーザーは個別の VNC サーバー・セッションを開始し、その VNC インスタンスに接続するためには正しいポート番号を指定しなければなりません。この要件はシングルユーザーのシステムでは許容できるかもしれせんが、マルチユーザー・コンピューターでは極めて厄介です。

この問題に対処するには、2 つの手法をリンクさせるという方法があります。この方法では、VNC に統合された X サーバーが VNC ではサポートされていないマルチユーザー認証を補うように、ローカル XDMCP サーバーを再構成することが可能です。この場合の構成は図 3 のようになります。破線矢印は、セッション開始を表します。このように構成すれば、リモート VNC のユーザーが VNC サーバー・コンピューターに接続するときに、そのユーザー名とパスワードを入力してユーザー固有の VNC セッションにアクセスできるため、コンピューターはユーザーを何人でも扱えるようになります。

図 3. XDMCP を VNC 構成に追加することで、柔軟性がさらに増します
XDMCP を VNC 構成に追加すると柔軟性が向上する仕組みを示す図
XDMCP を VNC 構成に追加すると柔軟性が向上する仕組みを示す図

VNC サーバーを構成する

VNC を起動するには、いくつかの方法があります。例えば、スクリプトを使用するという方法、デスクトップ・ツールを使って VNC をデスクトップ環境にリンクするという方法、あるいは xinetd を使用して VNC 接続をリッスンするという方法です。最後に挙げた方法では、VNC が XDMCP サーバーを使用するように VNC を起動できるので、この記事では xinetd を使用した方法を説明します。xinetd から起動されるように VNC を構成する前に、まずは VNC サーバーを選択する必要があります。

VNC サーバーを選択する

VNC サーバー・プログラムには複数の選択肢があります (「参考文献」に、これらのプログラムへのリンクが記載されています)。そのうちよく使用されているのは、TightVNC、TigerVNC、RealVNC です。この記事では、TightVNC を例として使用します。あいにく、構成の詳細はサーバーによってもディストリビューションによっても異なるため、使用しているソフトウェアに合わせて、記事で説明する手順を調整しなければならない場合もあります。

xinetd をインストールする

多くのディストリビューションでは、デフォルトで xinetd スーパーサーバーをインストールしますが、そうでないディストリビューションもなかにはあります。ここで説明する方法では xinetd を使用するので、xinetd がまだインストールされていない場合にはインストールしてください。ほとんどのディストリビューションでは、パッケージ・システムを使って xinetd をインストールすることができます。例えば、Debian ベースのディストリビューションでは「apt-get install xinetd」を実行し、openSUSE では「zypper install xinetd」を実行することでインストールできるようになっています。

xinetd を実行するために構成が必要になることもありますが、通常は System V (SysV) 起動スクリプトを使用して、その都度 xinetd を実行することができます。

# /etc/init.d/xinetd start

コンピューターのブート時に xinetd が自動的に実行されるように構成するには、お使いのディストリビューションの起動スクリプトを利用する方法に関する知識が必要です。通常この構成作業を行うために使用するユーティリティーは、chkconfig (Fedora、openSUSE、および関連ディストリビューションの場合)、update-rc.d (Debian および関連ディストリビューションの場合)、または rc-update (Gentoo の場合) です。以下に、それぞれの例を示します。

# chkconfig xinetd on
# update-rc.d xinetd enable
# rc-update add xinetd default

上記のコマンドのいずれかを入力するか、お使いのディストリビューションでこれらのコマンドに相当するコマンドを見つけてください。

xinetd にサービスが構成されていないと、xinetd が起動しない可能性があることに注意してください。したがって、VNC サーバーを管理するように xinetd を構成してから、xinetd を起動することをお勧めします。

xinetd を構成する

xinetd で管理されるサーバーの構成ファイルは、/etc/xinetd.d ディレクトリーに配置されます。したがって、VNC を操作するように xinetd を構成するには、/etc/xinetd.d/vnc のような名前のファイルを作成または編集します (openSUSE をはじめとする一部のディストリビューションでは、VNC サーバー・パッケージがこれに該当するファイルをインストールします)。リスト 1 に、一例を示します。

リスト 1. xinetd 用の VNC 構成の例
service vnc
{
   disable     = no
   socket_type = stream
   protocol    = tcp
   wait        = no
   user        = nobody
   server      = /usr/bin/Xvnc
   server_args = -inetd -once -query localhost -geometry 1024x768 -depth 16
   type        = UNLISTED
   port        = 5900
}

上記のエントリーで設定している xinetd オプションの大半は、そのままにしておく必要があります。調整してもよいオプションには以下のものがあります。

  • service: VNC は、それぞれに異なるオプションを設定した複数のポートで実行することができますが、その場合には、リスト 1 の最初の行で VNC にポートごとに異なるサービス名を指定してください。
  • server: このエントリーは、VNC サーバーのメイン・バイナリー (通常は Xvnc という名前) を指すように変更する必要があります。
  • server_args: この後すぐに説明するように、これらのオプションのいくつかは、ほぼ確実に変更する必要があります。
  • port: VNC は 5900 以降の番号のポートを使用します。各ポートで異なるオプションを指定してサーバーを実行することができます。その場合には、インスタンスごとに固有のポート番号を割り当ててください。

xinetd 構成で最も注意しなければならないのは、サーバー引数の設定です。リスト 1 の引数をモデルとして使用するのでも構いませんが、以下の引数については、変更したほうがよい場合もあります。

  • -query localhost: このオプションは VNC X サーバーに対し、XDMCP 認証の際にローカル・ホスト・システムを調べるように指示します。あるコンピューターを中継用に使用して別のコンピューター上のプログラムにアクセスする必要がある場合には、このオプションを変更します。
  • -geometry 1024x768: VNC セッションの仮想解像度は、このオプションで設定します。この仮想解像度は、サーバー・コンピューター上で稼働している通常の X サーバーの解像度と同等である必要はありません。異なる解像度で実行される複数のエントリーを作成して、ユーザーがそれぞれのローカル・システムに都合の良い解像度を使用している VNC サーバーにログインできるようにすることも可能です。
  • -depth 16: このオプションは色深度を設定します。値を小さくすれば、それだけ表示の更新は速く行われるようになりますが、色数の多いデスクトップ環境で色彩豊かな成果物を表示しようとした場合に悪影響が出る可能性があります。有効な値の範囲は 2 から 32 です。

他にも多数のオプションがあります。また、VNC サーバーによって異なるオプションもあります。詳細については、お使いの VNC サーバーのドキュメントを参照してください。

XDMCP サーバーを構成する

ほとんどの Linux ディストリビューションの XDMCP サーバーは、ローカル・ディスプレイだけを管理するように構成されます。リモート・アクセスを可能にするためには、同じコンピューター上で稼働する VNC サーバーからのアクセス要求を受け入れるように XDMCP サーバーを再構成する必要があります。再構成の詳細は、どの XDMCP サーバーを使用しているかによって異なります。Linux で最もよく使用されている XDMCP サーバーは、GDM (GNOME Display Manager)、LightDM (Light Display Manager)、および KDM (KDE Display Manager) の 3 つです。それ以外の XDMCP サーバー (XDM など) には、以降の説明とは異なる調整が必要になります。いずれにしても、XDMCP サーバーを再構成した後には、サーバーを再起動しなければなりません。

XDMCP 構成ファイルを編集する

システムで使用されている XDMCP サーバーが不明な場合は、以下のように、ストリング dm のプロセス・リストを検索することによって明らかにすることができます。

$ ps ax | grep dm
  929 ?        Ss     0:00 /usr/bin/kdm
  962 tty7     Ss+    0:19 /usr/bin/Xorg -br :0 vt7 -nolisten tcp -auth \
                           /var/lib/xdm/authdir/authfiles/A:0-pp4shb
30157 pts/3    S+     0:00 grep --color=auto dm

上記の出力の最初の行から、KDM がサーバーとして実行中であることがわかります。したがって、VNC で XDMCP を使用可能にするには、このサーバーの構成ファイルを編集することになります。ほとんどの XDMCP プログラムの構成ファイルは同じようなフォーマットに従います。構成ファイルに含まれるセクションは、括弧で囲まれたセクション名で識別されます (例えば、[xdmcp])。セクション名の後の行は、等号を使用してオプションを設定します (例えば、enable=true)。表 1 に、構成ファイル名、セクション名、そしてよく使用されているサーバーで Linux XDMCP サーバーで XDMCP を使用可能にするために設定しなければならないオプションを要約します。

表 1. 各 XDMCP サーバーで VNC の XDMCP サポートを有効にするためのオプション
XDMCP サーバー構成ファイル名セクション名オプション
GDM/etc/X11/gdm/custom.conf[xdmcp]enable=true
KDM/usr/share/kde4/config/kdm/kdmrc[Xdmcp]Enable=true
LightDM/etc/lightdm/lightdm.conf[XDMCPServer]enabled=true

構成ファイルには、XDMCP セクションが含まれていることも、このセクションが完全に欠落していることもあります。XDMCP セクションがあるとしても、明示的に XDMCP のサポートを無効にしている場合や、オプションをコメントアウトしている場合、あるいはセクション内が空の場合もあります。構成ファイルの元の状態がどうであろうと、XDMCP セクションが存在すること、そして XDMCP のサポートが有効になっていることを確実にしてください。例えば、XDMCP を有効にするための KDM 構成は以下のようになります。

[Xdmcp]
Enable=true

一部のディストリビューションでは、追加のセキュリティー対策を有効にしていますが、これらのセキュリティー対策には緩めなければならないものもあります。その 1 つは、ファイアウォールです。ファイアウォール・スクリプトはディストリビューションによって異なることが多いため、ファイアウォールを変更する方法については、お使いのシステムのドキュメントを参照してください。ローカル・ホストがポート 177 にアクセスすること、VNC クライアントがポート 5900 (または VNC に使用している以外のポート) にアクセスすることを確実にする必要があります。

openSUSE では、XDMCP アクセスを含め、いくつかのタイプのアクセスを制御するために /etc/sysconfig/displaymanager という追加の構成ファイルを使用します。このファイルをテキスト・エディターで開いて、以下に示す行を検索してください。

DISPLAYMANAGER_REMOTE_ACCESS="no"

このオプションを “yes” に変更します。設定を “no” のままにしておくと、VNC サーバーへの接続時に XDMCP サーバーのログイン・プロンプトが表示されません。この変更は、他のほとんどのディストリビューションでは不要です。このファイルを使用するのは、openSUSE だけです。

XDMCP サーバーを再起動する

リモート・ログインを受け入れるように XDMCP サーバーを構成した後は、XDMCP サーバーを再起動する必要があります。SysV init ファイルを使用して X を起動するディストリビューション (Debian および Gentoo など) では、その init ファイルに以下のようにして restart オプションを指定することができます。

# /etc/init.d/gdm restart

システムがランレベルを使用して X を起動する場合 (Fedora および openSUSE など)、以下のようにテキスト・モード・ランレベル (通常は 3) に切り替えてから、GUI ランレベル (通常は 5) に戻す必要があります。

# telinit 3
# telinit 5

いずれにしても X はシャットダウンされるため、再起動する前に、X セッションで開いているすべての作業を必ず保存しておいてください。

構成のテストとデバッグ

以上の作業を完了した時点で、リモート・コンピューターから VNC クライアントを使用してログインできるようになります。例えば、ほとんどの Linux ディストリビューションには vncviewer というコマンドが用意されています。このコマンドを以下のように入力してください。

vncviewer

上記のコマンドによって、VNC から remotename にログインすることができます。VNC が適切に構成されていて正常に動作していれば、図 4 のような画面が表示されます。複数の VNC セッションをそれぞれ異なるポートに構成している場合、以下のように VNC セッション番号をホスト名の一部として渡すことによって、VNC セッション番号を指定することができます。

vncviewer :3

これで、(ポート 5903 の) セッション 3 にログインすることができます。

図 4. XDMCP と連動するように構成されている VNC は、従来の Linux ログイン・プロンプトを表示します
VNC での従来の Linux ログイン・プロンプトを示す画面のスクリーン・キャプチャー
VNC での従来の Linux ログイン・プロンプトを示す画面のスクリーン・キャプチャー

以上のテストを実行して XDMCP ログイン画面が表示されないとしたら、デバッグを行う必要があります。確認すべき事項には、以下の内容が含まれます。

  • 接続が拒否されたことを vncviewer が報告している場合、最も高い可能性として、スーパーサーバーが VNC サーバー・コンピューター上で適切に構成されていないことが考えられます。xinetd 構成を再確認してから、スーパーサーバーを再起動してください。また、ファイアウォールが VNC サーバー・コンピューターへのアクセスをブロックしている可能性もあります。
  • VNC クライアントは正常に起動され、サーバーへの接続が行われるものの、グレーの画面とカーソル (画面上で移動することは可能) しか表示されないとしたら、おそらく XDMCP サーバーの構成に問題があります。上記で説明した設定を再確認してから、XDMCP サーバーを再起動してください。
  • 一般的なトラブルシューティング手法として、ログ・ファイルを調べてください。/var/log に格納されているすべてのログ・ファイルで、xinetd、XDMCP サーバー、および VNC サーバーへの参照を検索しなければならない場合もあります。

VNC のセキュリティー上の懸念事項

RFB は、セキュアなプロトコルではありません。ほとんどの VNC クライアントおよびサーバーは、データを暗号化しないためです (VNC は、自身のパスワードは暗号化しますが、この記事で説明している方法では VNC のパスワードを使用しません)。VNCをデプロイする場所とその方法については、慎重に検討してください。VNC を非セキュアなネットワークで使用しなければならない場合には、次の 3 つの選択肢があります。

  • VPN (Virtual Private Network) を使用する
  • プロトコルを SSH でトンネリングする
  • 暗号化をサポートする VNC のバリエーションを使用する (例えば、TLS (Transport Layer Security) 暗号化を使用可能にする TigerVNC など)

この記事で説明した方法で VNC によるログインを可能にすると、少なくとも 2 つのポート (VNC ポートと XDMCP ポート) が外部に対して開かれることになります。これらのポートが悪用されるリスクを最小限に抑えるには、両方のポートにファイアウォール・ルールによる制限を設けるとよいかもしれません。XDMCP ポート (UDP ポート 177) はローカル・ホストに対してのみ開く必要があるため、このポートのファイアウォール・ルールは非常に制限されたものにすることができます。

まとめ

概して VNC と XDMCP をリンクさせる方法は、マルチユーザーの Linux コンピューターに対して GUI によるリモート・ログインを可能にするための有効な方法となります。この方法は、クロスプラットフォーム環境で XDMCP を直接使用するよりも優れており、ファイアウォールや NAT への対策が問題になる場合にも役立ちます。マルチユーザー・コンピューターには、この手法のほうが、一般的に使用されている直接的な VNC 手法よりも優れています。ただし、VNC と XDMCP をリンクして使用する場合には、必ずセキュリティー上の問題を検討してください。外部からの望ましくないアクセスを制限するためにはファイアウォール・ルールを設定し、データが信頼できないネットワークを経由して転送される場合には暗号化を使用する必要があります。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Open source, Linux
ArticleID=818637
ArticleTitle=VNC でマルチユーザー・ログインを可能にする
publish-date=05312012