HOW TO RUN REMOTE X APPLICATIONS Vincent Zweije, zweije@xs4all.nl 15 November 1997 Tetsu Isaji, isaji@mxu.meshnet.or.jp 1 Feb 1998 この文書はXアプリケーションをリモートで起動する方法、設定、セキュリ ティについて解説しています。 ______________________________________________________________________ 目次 1. イントロダクション 2. 想定する状況 3. ちょっとした理論 4. クライアントに指定する 5. サーバに指定する、サーバ側の設定 5.1 Xhost 5.2 Xauth 5.2.1 クッキーを作る 5.2.2 クッキーの転送 5.2.3 クッキーを使う 5.3 ssh 6. トラブルシューティング ______________________________________________________________________ 1. イントロダクション これはXアプリケーションをリモートで使うためのガイドです。焦点はセキュ リティの実現にあてています。以下の理由からこのドキュメントを書きまし た。 1. 「Xアプリケーションをリモートでどのように使うか？」という質問 がusenetで多い。 2. X接続(X connections)をする為の"xhost +hostname"や "xhost +"を使うた めのヒント(心得)がある。xhostはセキュリティ上よくないもので、他によ い方法がある。 3. オプションについて記述したドキュメントを知らないのでもしもっと多く の情報があれば著者zweije@xs4all.nlまで教えて下さい。 このドキュメントはUNIXライクなシステムを対象に書かれています。ローカル あるいはリモートオペレーティングシステムでちょっと凝った使い方をしたい 時など、この文書でどのように動作させるかわかります。以下例として書いた ことは各自のシステムに合わせて変更して下さい。 Tkが「ディスプレイが安全ではありません」と表示するさい、何をすべきかと いうことについてWWW上に関連ドキュメントがあります()。 Kevin Kenny氏によって書かれたもので す。このドキュメント(xauth)ではX認証についてこの文書と同じような解決方 法を扱っています。しかしKevin氏はxdmを使う時にxauthを扱うことを目的と しています。 O'Reillyの X System Window System Vol. 8 Window System Administrator's Guide と関連文献はよい情報源なので注意を払っていますが、まだこの文献を チェックしていません。 他のドキュメントは"Securing X Windows"というタイトルです。 で入手できます。こ れはバージョン0.3.1です。善意により公開されていて無保証です。提案、ア イディア、追加、役立つポインタ、(打ち間違い等の)訂正などを募集していま す。この文書はシンプルな文書ですが、よい意味でHOWTO形式にしています。 文句なら /dev/null にでも捨ててください。 このドキュメントの最新版は で入手できます。また不定期にcomp.windows.xニュースグループに投稿してい ます。また「Remote X Apps mini-HOWTO」として で入手できます。 2. 想定する状況 2台のコンピュータがありそのうち1台目でXウィンドウシステムを使っていま す。2台目で大切なグラフィックの仕事をして、1台目のディスプレイに2台目 の出力を表示させたいというケースを考えます。 もちろんネットワークが必要です。なるべく速いものです。 Xプロトコルは ネットワークを大食いするからです。ですがちょっと我慢すれば適当なプロト コル圧縮(protocol compression)を使ってモデム経由でアプリケーションを実 行することができます。Xプロトコル圧縮については か をチェックして下 さい("LBX mini-HOWTOとして知られています)。 これらを行うために以下２つのことをしておきます。 1. リモートコンピュータからの接続の許可を、ローカルディスプレイ (サー バ)に指定する。 2. リモートアプリケーション(クライアント)に、その出力をローカルディス プレイに表示することを指定する。 3. ちょっとした理論 マジックワード(magic word)はDISPLAYです。Xウィンドウシステムではディス プレイは (単純化して)キーボード、マウス、スクリーンから成るといえま す。ディスプレイはサーバプログラム(Xサーバ)によって管理されます。サー バは、サーバに接続している他のプログラムに対して"表示できる資格"を与え ます。 ディスプレイは名前で表されます。例えば、 o DISPLAY=light.uni.verse:0 o DISPLAY=localhost:4 o DISPLAY=:0 といった具合です。ディスプレイはホスト名(例え ばlight.uni.verseやlocalhost)、コロン(:)、数字 (0とか4)から成りま す。ディスプレイのホスト名はXサーバが走っているコンピュータの名前で す。ホスト名が省略されるとローカルホストが指定されます (訳注：:0, :1, 0.1 などと指定したときはローカルホストになります)。数字は普 通0です -- もし一台のコンピュータに接続されたディスプレイが複数ある 場合はこの数字が変わることもあります ディスプレイの指定には.nを付けます。この.nはスクリーン番号です。ディス プレイは複数のスクリーンを持つことができ普通はひとつのスクリーンで n = 0とします。 4. クライアントに指定する クライアントプログラム(わかりやすくするためにグラフィックアプリケー ションとします)はDISPLAY環境変数を調べて接続するディスプレイを認識しま す。実行するときにクライアントのコマンドラインに-display hostname:0 オ プションを追加することでもでき、設定を変更することができます。いくつか 例を説明しましょう。コンピュータはlight、ドメイン名はuni.verseとしま す。もし普通にXサーバを走らせているなら、ディスプレイ はlight.uni.verse:0 として指定されます。リモートコンピュー タ(dark.matt.er)に描画ツールのxfigを起動させてローカルマシンlightに出 力を表示させます。 リモートコンピュータでcshを使っているなら dark% setenv DISPLAY light.uni.verse:0 #環境変数の設定 dark% xfig & とします。 あるいは、 dark% xfig -display light.uni.verse:0 & としても同じです。 shの場合は dark$ DISPLAY=light.uni.verse:0 dark$ export DISPLAY dark$ xfig & となります。同様に dark$ DISPLAY=light.uni.verse:0 xfig & してもよいですし、 dark$ xfig -display light.uni.verse:0 & ともできます。 5. サーバに指定する、サーバ側の設定 サーバはどこからでも接続できるというわけではありません。誰彼となく自分 のディスプレイにウィンドウを表示されたくはないでしょう？また入力したも のを読む時、キーボードはディスプレイの一部なのだということを忘れないで 下さい。ディスプレイ上にアクセスできるということがセキュリティリスクを 生じさせるということを理解しているひとはほとんどいません。ディスプレイ にアクセスできる人は、スクリーン上でものを読んだり書いたりできるので す。またあなたのキーストロークやマウスの動きを読むことだってできてしま います。ほとんどのサーバには２つの認証接続の方法があります。 hostリス ト機構(xhost)とマジッククッキー(magic cookie)機構(xauth)です。ま たssh(secure shell)があればX接続を転送することもできます。 5.1. Xhost Xhostはhost名にもとづいてアクセスを行います。サーバは、接続を認められ たhost のリストを管理します。hostのチェックを完全に無効にすることもで きます( 注意：無効にするとチェックが行われなくなるので全てのhostが接続 できてしまいます！)。 xhost プログラムを使ってサーバのhostリストをコントロールすることができ ます。上の例でこの機能を使うには light$ xhost +dark.matt.er とします。これはdark.matt.erからの接続を全て許可します。Xクライアント が接続されウィンドウが表示されたらすぐにセキュリティの為に接続許可を取 り消します。 light$ xhost -dark.matt.er light$ xhost + とすればhostチェックしません。これはhostのアクセスチェックを無効にして 誰でも接続できるようにしています。ユーザーが信用できない場合(例えばイ ンターネットに接続している場合)はこのような許可は決してしないでくださ い。 light$ xhost - "xhost -"とするだけではアクセスリストから全てのhostを削除できません(こ れはあまり使えません。どこからも接続できず、ローカルホストさえからも接 続できません)。 xhostはとても危なっかしい仕組みであると言えます。リモ ートホスト上のユーザーを区別できないし、host名(アドレスも同様)を偽って 使うこともできてしまいます。もし十分信用できるネットワークに接続してい ない(PPPでインターネットに接続しているなど)のならこれは良くないことで す。 5.2. Xauth Xauthは機密を知っているユーザーにアクセスを許可するものです。そのよう な機密は認証レコード(authorization record)あるいはマジッククッキー (magic cookie)と呼ばれます。異なるディスプレイ用のクッキー は~/.Xauthorityに用意されています。 ~/.Xauthorityはグループユーザーお よび他ユーザーにはアクセスできないようにしておきます(訳注：chown 600 .Xauthorityとしておきます)。セッションを始める際、サーバはクッキー を-authで指定したファイルから読みます。その後サーバは同じクッキーだと 判断したクライアントからの接続のみを許可します。~/.Xauthorityのクッキ ーが変更された時、サーバはこの変更を取り出すことはしません。 最近のサーバはすぐにリクエストしたクライアント用のクッキーを作ります。 クライアントが~/.Xauthorityにクッキーを追加しない限り ~/.Xauthorityに は入りませんが、クッキーはサーバ内に保存されます。 David Wiggins氏によ ると： より新しい機能が X11R6.3で追加されました。たぶん読者にも興味あることで しょう。新しいセキュリティ拡張機能を通して、Xサーバはすぐに新しいクッ キーを作って返します。さらにクッキーは「信用されない」ものに対しても指 定できるので、クッキーのような接続を行うアプリケーションはそれに関する 操作のみに制限されます。例えばキーボード/マウスの入力やウィンドウに表 示されていることなどを他の信用できるクライアントからでさえも盗み見るこ とはできなくなります。xauthで少なくともこの機能を使うための新しいサブ コマンドがあります。 xauthはxhostに比べてセキュリティ的に優れています。また特定のコンピュー タの特定のユーザだけにアクセスを制限することができます。xhostのような でたらめなアドレスからの接続はできません。必要ならxauthの後でxhostによ る接続ができます。 5.2.1. クッキーを作る もしxauthを使いたいのであれば、-auth (認証ファイル)を引数に付けてXサー バを起動する必要があります。startxスクリプトをつかっている場合はそこに 書いてもよいでしょう。以下のようにしてstartxスクリプトに認証レコー ド(authorization record)を書いて下さい。もしurandomデバイスがない場合 はほかのランダムデータを生成するものを使います。ps -axlが多分それで しょう(訳注：たいていの配布パッケージにはurandumデバイスがあります。特 にないという場合はMAKEDEVして下さい)。 /usr/X11R6/bin/startxからの引用： dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q xinit -- -auth "$HOME/.Xauthority" これは著者のstartxから引用したものです。startxスクリプトのカスタマイズ についてはmanページの、 tartx(1x), xinit(1x), xauth(1x), md5sum(1)を 参照して下さい。もしxauthが"不適切な行が追加されています(illegal add line)" と警告したら、md5sumのバージョン(訳注：md5sumはMD5の計算と チェックを行うプログラムです)にダッシュ(-)が(標準入力を計算す るchecksumに)追加されている可能性があります md5sumダッシュ(-)を使えな い場合はsedを使って取り外す(strip)ことができます。以下のようにsedコマ ンドの引数を変更してみて下さい。これはダッシュを追加しないmd5sumsと同 じように動作すべきですが、わかりやすいものではないでしょう。 (Thanks Jeffrey) ... 's/^\([0-9a-f]*\).*$/add :0 . \1/' ... rootにはなれなくてstartx スクリプトを編集できない場合はシステム管理者 に変更してもらうように言うか、代わりにxdmを設定するように言ってみて下 さい。管理者がそれをしない/できない時は、~/.xserverrcスクリプトを作る こともできます。このスクリプトは実際のXサーバの代わりに xinitによって 実行されます。そこで適当な引数でこのスクリプトからXサーバを起動しま す。そうするために~/.xserverrcでクッキーを作るためのマジッククッキーの 行を追加してXサーバを起動します。 #!/bin/sh dd if=/dev/urandom count=1|md5sum|sed -e 's/^/add :0 . /'|xauth -q exec /usr/X11R6/bin/X "$@" -auth "$HOME/.Xauthority" Xセッションを操作するためにxdmを使う時は簡単にxauthが使えます。 /etc/X11/xdm/xdm-configのDisplayManager.authDir リソースを定義して下さ い。xdmはXサーバが起動する時に -auth 引数を パスするようになります。詳 しくは xdm(1) を参照して下さい。例えば著者の /etc/X11/xdm/xdm-configで は以下の行が書かれています： DisplayManager.authDir: /var/lib/xdm 5.2.2. クッキーの転送 light.uni.verse サーバホストでXセッションを開始して ~/.Xauthority の クッキーを取得します。クッキーをクライアントホスト(dark.matt.er)に転送 します。 light(サーバ)とdark(クライアント)ホストがホームディレクトリを 共有している時は話は簡単です。 ~/.Xauthorityファイルは同じなので、クッ キーを転送する必要はありません。共有されていない場合はrshによる方法で クッキーを転送できます。 rshを使ってリモートシェルで light$ xauth nlist :0 | rsh dark.matt.er xauth nmerge - としてクッキーを転送します。これは 1. ローカルの~/.Xauthorityからクッキーを引用する(xauth nlist :0)。 2. dark.matt.erに転送する(| rsh dark.matt.er)。 3. 転送先の~/.Xauthorityに置く(xauth nmerge -)。 ということを意味します。 rshが動作しないこともあります。またrshはセ キュリティ上の欠点もあります (ホスト名を偽ったりできる)。rshを使え ない/使わないなら以下のように手動でクッキーを転送することもできま す： light$ echo $DISPLAY :0 light$ xauth list $DISPLAY light/unix:0 MIT-MAGIC-COOKIE-1 076aaecfd370fd2af6bb9f5550b26926 light$ rlogin dark.matt.er Password: dark% setenv DISPLAY light.uni.verse:0 dark% xauth add $DISPLAY . 076aaecfd370fd2af6bb9f5550b26926 dark% xfig & [15332] dark% logout light$ 詳しくはrsh(1)、xauth(1x)を参照して下さい。 5.2.3. クッキーを使う xfigといったdark.matt.er(クライアント)上のXアプリケーションは認証に使 うクッキーを自動的に~/.Xauthorityから読みます。 5.3. ssh 認証レコードは暗証化されずに転送されます。誰かが接続をのぞくという心配 があるならssh(secure shell)を使って下さい。これは暗証化された接続を経 由してXをフォワードします。もちろん他にもよい方法はあります。システム に構造上よい発展を補うものです。 sshホームページ のhttp://www.cs.hut.fi/ssh/を見てみて下さい。 誰かX接続や認証方法について他に何か知っていませんか？kerberosかな？ [訳注： Kerberosについて、うえやま るいさん、岡本さんからのコメントを まとめました： ケルベロスはギリシャ神話に出てくる冥界の支配者ハデスの飼い犬で３つの頭 をもち冥界の門を守る番犬です。"Kerberos" は MIT の "Athena" 計画の一貫 として研究開発されました。RFC 1510 が 1993 年に発行されてます。 Kerberos は信頼できないネットワークで安全な認証・通信を行うために、信 頼できる第三者を使うシステムです。内部の暗号は 対称鍵暗号DESを使いま す。DESなのであまり強くはありません。しかし、チケットという仕組で認証 を行うので運用が簡単で、安全な認証と通信ができます。鍵配布センターを階 層化して、大規模なシステムにも対応することもできるようです。 ふつうの方法だと、クライアントがサーバを利用するときは相手が本当に本物 であるか互いに分かりません。そこで、お互いが信頼している第三者に身元保 証してもらえばよいという考えに基づいています。その第三者が鍵配布センタ ーというもので、その鍵配布センターにサーバを利用するためのチケットを発 行してもらいます。だれでもチケットを発行してもらえるわけはなくクライア ントとサーバの鍵を登録しておく必要があります。鍵配布センターに発行して もらったチケットは、クライアント(発行してもらう側) の鍵で暗号化されて いるので、これを復号できるということは、クライアントは確かに本人である ことがわかります(本人じゃなければチケットを取りだせないので、サーバを 利用することはできません)。 チケットは復号化した中に入っていて、このチケットはサーバの鍵で暗号化さ れています。そこで「サーバがチケットを復号化できる = サーバも確かに本 人である」ということになります(復号化した中にセッション鍵が入ってい て、それ以降の通信でこのセッション鍵を使うのため、本人以外は続行できま せん)。 この欠点は、チケットの再利用ができてしまうところです。攻撃者はチケット の内容を見れませんが、流れているチケットを拾ってそのままもう一回サーバ に送れば本人のふりをできます。そのために、タイムスタンプを暗号化して一 緒に送ります。古いタイムスタンプ付きのチケットは使えません。それに、サ ーバはタイムスタンプを記録しているので、まったく同じスタンプを持つチ ケットは無効です。 システム全体での欠点は、鍵配布センターが存在することです。鍵すべてを登 録しているので、ここを破られると安全もなにもありません。 XFree86 のマニュアルの翻訳(岡本さん)が JF にあります。 X の認証関係の 参考にしてください。また、国内では OPEN DESIGN No.14 CQ 出版社 ISBN4-7898-1806-3 C3055 \1748Eの「集中特集最新の暗号によるセキュリティ の実現」が参考になります。 ポインタ： o FreeBSDハンドブックのペー ジ：http://www.freebsd.org/ja_JP.EUC/handbook/handbook64.html#66 o http://www.releenet.co.jp/bsd/handbook/handbook60.html o Jun Kuwamuraさんのページ：http://stealth.rccm.co.jp/~juk/krb/ ] 6. トラブルシューティング はじめにリモートでXアプリケーションを起動しようしてもそのままでは動作 しません。以下2〜3のエラーメッセージ、原因、解決方法を挙げます。 xterm Xt error: Can't open display: DISPLAY環境変数がなく、またアプリケーションに-displayフラグオプション も指定されていません。アプリケーションは-displayで示された文字列がない ものとして動きますが、文法的に間違っています。これを解決するに はDISPLAY環境変数を正しく設定してみて下さい(シェルによっ てsetenv、exportコマンドのどちらかを使います)。 _X11TransSocketINETConnect: Can't connect: errno = 101 xterm Xt error: Can't open display: love.dial.xs4all.nl:0 アプリケーションはサーバにネットワーク接続できません。DISPLAY変数が正 しいかどうかチェックして、サーバがクライアントから接続できるかどうかも 確認しておいて下さい(サーバにログインした後にクライアントに telnetして みるなど)。 _X11TransSocketINETConnect: Can't connect: errno = 111 xterm Xt error: Can't open display: love.dial.xs4all.nl:0 接続しようとしているサーバマシンはありますが、指示しているサーバがあり ません。正しいホスト名とディスプレイ番号を使っているか確認して下さい。 Xlib: connection to ":0.0" refused by server Xlib: Client is not authorized to connect to Server xterm Xt error: Can't open display: love.dial.xs4all.nl:0.0 クライアントはサーバに接続されていますが、サーバは(許可されていない) クライアントを許可していません。正しいマジッククッキーをクライアントに 転送しているか確認して下さい。また終っていないかどうかも確認して下さ い(サーバは新しいセッションが開始すると新しいクッキーを使います)。 [ 校正：藤原 輝嘉さん, fujiwara@cim.pe.u-tokyo.ac.jp Kerberosについて：うえやま るいさん, rui@ic.netlaputa.ne.jp、岡本 一幸 さん, ikko-@pacific.rim.or.jp、 Jun Kuwamuraさん, juk@rccm.co.jp またJFの方達にも大変お世話になりました。ここに感謝いたします。]