NoMachine NX

atlsrv01/02 には NoMachine 社NX server [1] がインストールされています。

NX とは、X window データを圧縮して転送することにより、狭帯域、高 latency の Internet 接続下でも、実用的な X window 環境を実現するというものです。Server 側の接続は SSH の port (tcp/22) を利用していますので、SSH 接続の出来る環境ならば firewall 設定等を変更する事無く利用できます。また、転送データには SSH の暗号化が施されますので安全面も考慮されています。自宅の ADSL 接続環境 (~1 Mbps) や CERN からの access (RTT ~ 280 ms) でも、Emacs や Paw、Root、Firefox などの graphical な application が快適に使用できると報告されています。

Remote host の GNOME や KDE の desktop を表示する機能がありますので、VNCWindowsMac の Remote Desktop 的な物と見る向きもある様ですが、基本的には X window の進化形と考えるべきでしょう。通常の X window を起動して SSH で remote login する際と同じ様に、desktop 画面を出さずに application window だけを表示する事も出来ます。

NX server は Linux と Solaris 用しかありませんが、client は Windows、MacOSX、Linux、Solaris 用と、ほとんどの platform をサポートしています。Windows 版以外ではそれぞれの X window 環境を表示に使用します。従って、MacOSX 版では X11 の追加 install が必須です。Windows 版には Cygwin の X window engine が組み込まれている様です。

多分 security は十分に考慮されているのでしょうが、接続手順に security hole に成る可能性のある部分がありますので、念のため、利用開始時に簡単な手続 きを要求する運用形態を採る事にしました。

似た様なものに FreeNX というものがあります。多分、OpenSSH/OpenSSL の component を利用しているせいだと思いますが、NoMachine NX のライセンスは GPL に成っています。この為に source code を公開する義務が生じます。FreeNX はこの公開された source code を基にして開発された free software です。FreeNX は Fedora 等では yum で install できる様ですし、最近の Knoppix にも入っている様です。ただし、これは server 側だけで、client はありません。NoMachine 社が様々な platform 用のものを free で配布している為だと思います。このため、FreeNX 側の開発が間に合わず、NoMachine 社の最新の client との間に不整合が生ずるという事もある様です。atlsrv01/02 に install されているのは NoMachine 社の NX server です。

[1] 現在 install されているのは無償版の NX Free Edition です。同時に利用できるのは 2 users までという制限があります。利用が増えたら有償版に変更するつもりです。


利用方法
  1. NX client を各自で NoMachine 社の Web page から download して、自分の PC 等に install する。Windows 版では font の install も必要。
  2. 各自で「passphrase 無し」の SSH 公開鍵ペアを生成する。Linux、MacOSX を含む Unix 系 machine では
      > ssh-keygen -d -N "" -f nx_dsa
    で簡単に生成できます。暗号化は DSA でないといけない様です (-d option)。nx_dsa というのが作成する file 名ですが、これは何でもかまいません。この例では nx_dsanx_dsa.pub という二つの file が作られます。前者が秘密鍵で後者が公開鍵です。どちらもただの text file です。
  3. 公開鍵 (上の例では nx_dsa.pub) をメールの添付ファイル等で atlsrv01/02 の管理者 (私) に送る。atlsrv01/02 で鍵ペアを生成して、その公開鍵の在処を知らせてくれても良いです。
  4. 各自の NX client に秘 密鍵 (上の例では nx_dsa) を import する。NX Connection Wizard あるいは NX client を起動して接続の設定を 行った後、接続 dialog window の "Configure..." ボタンを click して、現れる Configure window で "General" tab の "Server" 項目中の "Key..." ボタンを click すると key import の window が現れる。ここで "Import" ボタンを click すると file 選択画面が現れるので、作成した秘密鍵の file を選択する。"File type:" を "All files (*)" にしないと秘密鍵の file が見えないので注意してください。file を選んで "OK" を click して選択画面を閉じて import window を "Save" で閉じ、さらに Configure window を "Save"、"OK" で閉じて import 作業終了です。管理者 (私) から「設定完了」の連絡が来たら接続可能です。-> 図解説明
作成した「秘密鍵」は各自で適切に保管、あるいは廃棄し てください。 atlsrv01/02 で生成して他の user から見える場所に置いておくなどというのは厳禁です。 自分の管理する複数の client で共通の秘密鍵を使用するのはかまいませんが、他人に渡すのはいけません。 これは一般的な「秘密鍵」のルールですから必ず守ってください。


設定方法

接続の設定は NX client の install で作成される "NX Connection Wizard" を起動しても行えますし、"NX client" を起動した時に現れる dialog でも行えます。前者は追加のみですが、後者では新しい接続名と接続先を書き込んで "Configure..." ボタンを click すると、追加か変更かを聞いてきます。また、既存の設定を選択して "Configure..." ボタンを click すると、設定の消去もできます。

Linux では NX client は /usr/NX/bin/nxclient。NX Connection Wizard は無い様です。NX client の install で /etc/profile.dnx.(c)sh が追加されて、login 時に /usr/NX/binPATH に追加されるはずですので、nxclient だけで NX client が起動するはずです。

細かい設定はほとんど必要ないと思います。接続名と接続先の指定以外は NX client の Configure 画面の "General" tab の内容程度で十分だと思います。"NX Connection Wizard" でも、内容は少し簡略化されていますが同じ様な設定画面が現れます。

nx_config.jpg

"Desktop" 領域では "Unix" 以外にも選択肢がありますが、これは NX client が VNC や Windows Remote Desktop 等にも対応している事に成っているのでその選択肢です。相手が NX server の場合は "Unix"  です。他はまだ真面目に試していませんので、本当に動くかどうか分かりません。

Remote host の desktop 画面を表示したい場合は、その右側で "GNOME" や "KDE" 等を選択します。実際に有効なのは atlsrv01/02 で動いているもの (GNOME と KDE) だけです。表示サイズは "Display" 領域で選べます。Application window だけで良い、desktop 画面は必要ない、という場合は "Custom" を選択します。この場合は表示サイズの選択はありません。

"Desktop" 領域の slide switch は network 速度の設定です。多分、これを基にしてデータ圧縮の基準を決めるのだと思います。実際の環境を考えて適切に (適当に?) 選択してください。

NX client は日本語キーボードを認識してくれません。常に英語 (ASCII) keyboard と解釈してしまう様です。日本語キーボードで使う場合は X window の設定で対処するのが良いでしょう。設定 script の例を atlsrv01/02 の /work/odaka/nx/ に置いておきました。NX client で接続して、この中の t4key を走らせて下さい。これは xmodmap を走らせているだけです。t4.keymap が設定 file です。自分の directory にコピーして使う場合は、t4key を編集して t4.keymap の path を書き換えて下さい。t4.keymap は私の Let's note T4 に合わせてあります。機種によって微妙に違うかも知れません。違う場合は t4.keymap を修正して下さい。xev を使えば各 key の keycode を調べる事が出来ます。


NX の動作

log を見ながら何をやっているのかを調べてみました。どうやら NX は以下の様な事をやっている様です。
  1. NX client はまず nx というユーザ名で、サーバに passphrase 無しの公開鍵認証で login する。NX server の install 時に nx というユーザが作られます。
  2. login に成功すると nx というユーザは直ちに /usr/NX/bin/nxserver --login を実行する。これは公開鍵 (/usr/NX/home/nx/.ssh/authorized_keys2) に書き込まれています。SSH 公開鍵認証にはこのような機能が組み込まれているのだそうです。
  3. nxserver --login でユーザ nx は local に通常ユーザ名での login を行う。NX server はクラスターもサポートしていて、登録された nodes から自動的に login する node を選択する機能もある様ですが、NX Free Edition では単に localhost に login するだけです。この login は password 認証で、username/password は NX client で与えられたものです。
  4. この通常ユーザの login が成功して X client application が実行されると、そこからの X window data は nx の起動した nxserver が受け取る事に成ります。そこで独自形式の data に作り替えて remote の NX client との間で data の遣り取りをする、という仕組みに成っている様です。
ここで問題に成りそうなのは、1. の「nx というユーザ名での passphrase 無しの公開鍵認証」です。NX client と NX server は独立に install される訳で、事前に遣り取りは無い訳ですから、世の中の全ての NX server/NX client は同じ公開鍵ペアを持っている事に成ります。 すなわち、ある server にユーザ登録をしていなくても 1. は誰でも成功する事に成ります。 まあ、1. が成功しても nxserver --login が起動されるだけだし、十分なセキュリティー対策はされていると思いますが、何となく気持ちが良くありません。 Security hole が無いとも限りません。 まだ世の中に NX の存在が余り知られていないのでそれ程心配は無いと思いますが、普及してきたら必ず出て来ると思います。 この様な懸念から、NX を解説している Web page の多くで、独自の公開鍵ペア生成とその設定方法が説明されているのだと思います。

ということで、やはり心配なので atlsrv01/02 でも上記の様に公開鍵認証をちゃんとやろうという事に成りました。 共通の秘密鍵を配布するとか、NX の待ち受け port を替えて SSH tunnel でしか login 出来ない様にするとか、いろいろ考えたのですが、やはり一番原則に則った方法が良いのではないかという結論に達しました。


2008.7.11, S. Odaka