レベル: 初級 David Mertz (mertz@gnosis.cx), President, Gnosis Software, Inc.
2001年 12月 01日 この2回シリーズの記事の第1回において、Davidは、セキュア・シェル (SSH) とVirtual Network Computing (VNC) を比較して違いを明らかにします。この2つの技術を利用すると、あるワークステーションから、別のコンピューターにあるアプリケーションを実行できます。ファイルとプリンタの共用や、HTTPD、FTPD、SMTP、NNTPDなどの "インターネット"・サービスといった技術も、このような環境においてコンピューター資源を "共用する" のに役立ちますが、この記事ではこれらの技術には触れません。一方、SSHとVNCのインストールと構成についてはヒントを示し、ツールの安定性、選択、およびライセンス交付状況に触れています。
さまざまなソフトウェア・プログラムのテストと作成を効率よく行うため、私は多数のコンピューターをローカル・ネットワークに接続しています。これらのマシンでは、複数のオペレーティング・システムが稼働し、多様なハードウェア構成が使われています。このような環境を利用して、ツールをさまざまなプラットフォームで評価したり、自分で作成したツールのテストとデバッグを行ったりしています。
ネットワークに接続されているマシンのほとんどには複数のオペレーティング・システムがマルチブート構成でインストールされていますが、中にはモニターやキーボードの付いていない "首なし" のマシンもあります。マルチブート・ローダーは持っていると便利ですが、リブートに時間がかかるため、1台のマシンだけでプラットフォームの詳細な比較テストを行うにはかなりの時間を要します。マルチブートは、"見比べて" 比較を行うには適していません。VMWare、Plex86、VirtualPC、SheepShaverなど、あるオペレーティング・システムを別のオペレーティング・システムの中で "仮想化する" ツールの評価は行っていません。これらのツールは、この記事で説明しようとしているものと同様の目的を、ある点では満たしています。
あるワークステーションで別のコンピューターにあるアプリケーションを実行できる技術は、1種類だけではありません。SSHは、リモート・コンピューターに対するテキスト端末を提供します。X Windowシステムを使えば、対話型アプリケーションを、それが実際に動作しているものとは別のワークステーション上で表示できます。VNCは、リモート・デスクトップ全体に対する "リモコン" として機能します。それぞれの技術には、長所と短所があります。いずれもLinux上で動作しますが、異なるバリエーション (ホストまたはリモート) を利用することで、さまざまなOS環境との対話が可能になります (異機種ネットワークの場合)。これらのツールを組み合わせて使えば、1台のワークステーション (最も使いやすいモニターとキーボードといすを備えたもの) の前に座ったまま、さまざまなプラットフォーム群でアプリケーションの実行や、テストや、時間測定を (通常は何もリブートしないで) 実行できます。
ネットワークのセットアップ
私のローカル・ネットワークには7つのノードがあり、Apollo、Bacchus、Chaos、Delphi、Echo、Fury、そしてGaiaという名前が付いています。これらのノードには、192.168.1.101から192.168.1.107までのローカルIPアドレスを、上記の名前の順に割り当ててあります。通常は、別のオペレーティング・システムへのマルチブートを行うと、同じ物理マシンには同じIPアドレスが割り当てられます(ただし、DHCPを使って192.168.1.200以上のアドレスを割り当てる場合もあります)。すべてのものはハードウェアのファイアウォール/ルーターの内側に置いてあり、ファイアウォールは十分に信頼できるものなので、ローカル・マシン上で動作するサービスについて必要以上の心配はしていません。公衆インターネットを通してコンピューターを共用する必要がある場合は、セキュリティーの問題についてもう少し心配する必要があります。この第2回の記事では、セキュリティーの問題について若干の説明を行います。
上のような詳細を説明したのは、主として、以下で示すシェルの例を理解できるようにするためです。実際に私の目の前にあるマシンはBacchusで、そのローカルIPアドレスは192.168.1.102です。
セキュア・シェル (SSH)
帯域幅に最も負担をかけないでコンピューターを接続するには、単純なテキスト・シェルを使用します。Telnet やRSH などはそのための非セキュアなツールですが、これらのツールを使うとセキュリティー上の問題が数多く発生するので、たいていは、通信を行う必要のあるコンピューターにSSH をインストールする方が無難です。以下で示す例の中にはファイアウォールの内部でTelnet を使用しているものがありますが、このような方法を使用しているのは、"Fury" を使ってテスト用オペレーティング・システムのインストールと再インストールを行っているためです。多くのUNIX系オペレーティング・システム (最新のLinuxディストリビューションを含む) では、SSH がデフォルトでインストールされます。インストールされていない場合は、後の参考文献を参照してセットアップを行ってください。
セキュア・シェル (SSH) は、特定のチャネルを通過するすべてのトラフィックを暗号化します。公開鍵暗号化方式が使用されるので、セッションを開始する前にサーバーとクライアントが鍵を共有する必要はありません。さらに、機密情報が非暗号化形式でチャネル上を伝送されることはありません (ログイン・パスワードなど。Telnet は盗聴者に対してもこのような情報をあからさまに伝送してしまいます)。VNCやX Windowのような他のプロトコルをSSH の上に階層化できますが、リモート・テキスト・コンソールを作成するのが、プロトコルの最も簡単な使い方です。
SSH を使うと、ローカル・マシンとは異なるオペレーティング・システムを使用しているマシンに簡単に接続できます。唯一の要件は、リモート・マシンでSSHD サーバーが稼働していて、ローカル・マシンにSSH クライアントがあることです。たとえば、OS/2 Warpマシンの "Bacchus" を隣の部屋にあるSlackware Linuxマシンの "Delphi" に接続する方法は、次のように非常に簡単です。
SSHを利用したHOSTS名によるリモート・ボックスへの接続
C:\UTILS % ssh quilty@delphi
Last login: Thu Nov 29 01:41:36 2001 from 192.168.1.102
Linux 2.2.19.
quilty@delphi:~$ exit
logout
Connection to delphi closed. |
HOSTS
ファイルでエイリアスが定義されていない場合は、次の方法を使います。
SSHを利用したIPによるリモート・ボックスへの接続
C:\UTILS % ssh quilty@192.168.1.104
Last login: Thu Nov 29 01:51:31 2001 from 192.168.1.102
Linux 2.2.19.
quilty@delphi:~$
|
同様に、私は次の方法を使って、リースしているWebサーバーの管理を国中や世界中から頻繁に行います。
SSHを利用したDNS名によるリモート・ボックスへの接続
C:\UTILS % ssh gnosis@gnosis.cx
gnosis@gnosis.cx's password: |
異種プラットフォームで
SSH を使用する場合に最も難しいのは、端末を正しく構成することです。この問題は、実際にはSSH 自身の問題ではありません (Telnet でも同様の問題が発生する傾向があります)。2台のLinuxマシンの相互接続は、普通、シームレスに動作します。しかし、クライアントまたはサーバーで別のプラットフォームが使われていると、表示が正しくなかったり、キーのバインディングが意図したとおりに動作しなかったりすることがよくあります。これはWin32、BeOS、MacOS、OS/2などの非UNIX系プラットフォームが関係する場合だけの問題のように見えますが、FreeBSDとLinuxの接続も完全ではありません。
異種マシン間のSSH
接続を作成する際の最も典型的な問題は、コード・ページまたはカラー・エスケープ・コードの誤りです。どちらかの問題が発生すると、基本的なコマンド行は使用できますが、線画文字は正しく表示されません。カラー端末がモノクロ端末として表示されることもよくあります。シェル・コマンドはこのような "インピーダンスのミスマッチ" からはあまり影響を受けませんが、
curses タイプまたはslang タイプの対話型アプリケーションは、通常、大きな影響を受けます。このようなアプリケーションで最も注目すべきなのはテキスト・エディターです。普通、テキスト・エディターは、リモート・コンソールから実行しなければならいことが最も多いアプリケーションです。ところで、jed は非常に優れたテキスト・モード・エディターです。勇気のある人はおそらくvim を使用するでしょう。他のほとんどのLinux/UNIXエディターは、Xベースであるか、またはあまりにもお粗末なものです (emacs は派手すぎです)。
端末の構成に関して問題がある場合は、手を加える個所がいくつかあります。UNIX系のSSHD サーバーに接続している場合は、リモートのTERM 環境変数を次のように変更してみてください。
一般的なリモート端末の設定
quilty@delphi:~$ TERM=vt100
quilty@delphi:~$ TERM=ansi
quilty@delphi:~$ TERM=linux |
また、ローカルのSSH クライアントには、普通、接続の端末タイプを構成する手段があります。プラットフォームおよびクライアント・プログラムの種類により、この手段は、コマンド行オプションであったり、環境変数であったり、メニュー・ダイアログであったりします。両方で使用している名前が、まったく同じではない可能性があります。若干の試行錯誤が必要になります。また、クライアント構成の中で "コード・ページの非変換" を使用していることを確認する必要があります。"インピーダンス・マッチ" をテストするには、フルスクリーンのリモート・アプリケーション (jed や他のエディターなど) を実行してみます。
Virtual Network Computing (VNC)
VNCは、多くのGUIプラットフォームに移植されているクライアント/サーバー・システムです。VNCは、ローカル・システム上にリモート・コンピューターの "デスクトップ" 全体を表示するための軽量プロトコルを提供します。SymantecのpcAnywhere は、同様の目的で開発された製品ですが、Microsoftのオペレーティング・システムでしか動作しません。それに対し、VNCは、現実に数十種類以上のオペレーティング・システムで動作し、多くの実装とバリエーションが存在しています。
VNCがどのようなものかを知るには、VNVのWebサイト (参考文献を参照) でスクリーンショットを見てみるといいでしょう。Webサイトで示されているよりはるかに多くの可能な組み合わせがありますが、紹介されているバリエーションからもその多さがわかります。一般に、VNCクライアント (通常、vncviewer と呼ばれます) を備えるすべての プラットフォームは、VNCサーバー (vncviewer) を備える任意のプラットフォームの仮想デスクトップをローカル・ウィンドウ内に表示できます。VNCクライアントのバージョンによっては、サイズ変更やフルスクリーン・オプションも利用できることがあります。
Xベース・バージョンのVNCサーバー (Xvnc) と他のプラットフォームのVNCサーバーでは、若干の違いがあります。Windows、MacOS、BeOS、OS/2などのシングル・ユーザー・システムには、X Windowシステムで行われているような "デスクトップ・セッション" の概念はありません。したがって、たとえばWindowsのVNCサーバーは、ローカル・システムで表示されているものと同じWindowsデスクトップのリモート・バージョンを表示するだけです。このデスクトップは、接続時には "desktop :0" という名前で呼ばれます。一方、X Windowはマルチ・ユーザーおよびマルチ・セッションのシステムです。各Xvnc セッションは、新しいデスクトップを作成し、独自の解像度やウィンドウ・マネージャーや状態を持つことができます。つまり、VNCにはXの方がはるかに適しています。
VNCサーバーが一度インストールされてしまえばセッションを起動するのは簡単ですし、インストールは容易です (参考文献を参照)。シングル・ユーザー・プラットフォームの場合は、基本的にアプリケーションを実行するだけで、オプションはありません (最初にアクセス権を設定する必要があります)。Xの場合は、いくつかのコマンド行オプションが役に立ちます。たとえば、OS/2 Warpのローカル・マシン "Bacchus" からMandrake Linuxマシンの "Fury" にTelnet セッションを接続するときは、次のようなオプションを使用します。
FuryでのVNCサーバー・セッションの開始
[root@fury quilty]# cat /usr/bin/vnc-sessions
vncserver -name TinyLinux -depth 8 -geometry 640x480
vncserver -name BigLinux -depth 32 -geometry 1260x940
[root@fury quilty]# vnc-sessions
New 'TinyLinux' desktop is fury.gnosis.lan:1
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/fury.gnosis.lan:1.log
New 'BigLinux' desktop is fury.gnosis.lan:2
Starting applications specified in /root/.vnc/xstartup
Log file is /root/.vnc/fury.gnosis.lan:2.log |
クライアント側からは、ローカルのvncviewer を使って、Fury:1 とFury:2 のどちらか一方へ、または両方へ同時に接続できます。また、必要であれば192.168.1.106:1 を明示的に指定することもできます。
非ローカルのネットワークに対しても同じ方式を使用でき、セキュリティーを確保するためにSSHを通したトンネルを形成するようにVNCを構成できます。
ほとんどの場合、リモート・コンピューターへvncviewer 接続をすることは、そのリモート・コンピューターのローカルのモニターとキーボードの前に座っているのと同じことになります (リモート・コンピューターがヘッドレスではない場合)。見た目には、リモート・システムのデスクトップは、ローカル・マシンのウィジェットを使用するウィンドウによって区切られます (フルスクリーン・オプションを使用していない場合)。この余計なフレームは最初少し気になりますが、しばらく使っている間に気にならなくなります。
適切なセッション形状とカラーの濃さを選択することが重要です (選択可能なXvnc サーバーを使用している場合。または、他のvncserver プラットフォームの場合は、リモート・コンピューターのローカル・ディスプレイをVNCの必要性に適した解像度に切り替える場合)。リモート・デスクトップを小さくするほど、そして色数を少なくするほど、表示の応答が速くなります。そうはいっても、多くのアプリケーションは画面上にいくらかの領域を要求します。表示色の段階を少なくしても応答性にはほとんど影響がないことがわかりました。画面の純粋なピクセル単位の伝送より、VNCのhextileエンコード方式の方がはるかに効率的です。ただし、明らかに、画面のサイズによって違いがあります。
大体において、リモートの1260ｘ940以上の領域を、私のローカルの1280ｘ1240のビデオ設定で非常に快適に使用出来ることが分りました。VNCのタイトル・バーとローカル・デスクトップのタスクバーには、ほんのわずかな領域だけを残すようにしています。ただし、vncviewer ウィンドウはそれでも画面のほとんど 全体を占めますが、快適に動作します。100Mビットのイーサネット接続では、ローカル・ディスプレイと比較してほとんど見劣りしません。10Mビットのイーサネットでは、ウィンドウの位置やサイズを変更したときに若干の遅れを感じます。通信速度が遅くなるほど、VNCはリモート操作のソリューションとして適さなくなります。ケーブル、DSL、またはT1接続ではまだ動作可能ですが、シームレスではなくなります。これより遅いものはすべて、事実上、緊急時にだけ使用します。
VNC接続に関する問題の1つは、ローカル・デスクトップにおいて余分にキー・ストローク操作をしなければならないことです。クライアントの種類に依存しますが、いくつかのリモート・キー・ストロークを複数のキー・ストローク操作でエミュレートする必要がある場合があります。たとえば、ローカルOS/2vncviewer では、リモートのAlt-F を入力するためにAlt-A、F、Alt-A を押す必要があります。ブラインド・タッチに慣れたユーザーの場合、このような余分なキー・ストロークは面倒です。独自のキーボードと1ボタン・マウスを使用するMacのような非PCプラットフォームでは、さらに複雑になります。覚えたり入力したりしなければならないことは若干多くなりますが、一般に、任意のリモート入力アクションをエミュレートする手段はあります。ただし、Linux同士の接続の方が、はるかにスムーズに動作します。両端で使われているウィンドウ・マネージャーの種類によって異なりますが、通常、リモート・セッションに直接渡されないキーの組み合わせの数はわずかです。
VNCの注目すべき実装の1つは、Javaバージョンです。多くのネイティブ・バージョンを利用できますが、ネイティブなvncviewer のないプラットフォームでもJavaバージョンは使用できます (プラットフォームにJVMがある場合)。VNC-JavaはWebブラウザーで動作するので、使い慣れたインターフェースで接続を確立できます。ただし、Javaビューアーは、ブラウザーを使わずにJavaアプリケーションとして実行することもできます。次の参考文献では、VNCをこれから使うユーザーへ何かの役に立つようにと、私自身が作成したアーカイブを含め、VNC-Javaについての追加情報が紹介されています。
次回の予定
第2回では、ネットワークを介してリモート・アプリケーションを実行するためのリモートXやその他の手段、およびリモート・アプリケーションを使用する際のセキュリティーに関する問題について説明します。
参考文献
SSHの参考文献
- ほとんどのLinuxディストリビューションには、代わりにOpenSSH が付属しています。さまざまな場所から継承しているためにライセンスは少々複雑ですが、"BSDと似た" ライセンスです。
-
FreeSSH (FreSSHではありません) のサイトには、さまざまなプラットフォームでのフリーSSH実装や市販SSH実装へのリンクがあります。
- Windowsの場合は、フリー・ソフトウェア・プログラム (MITライセンス) であるPuTTY をお勧めします。このソフトウェアは非常に優れたもので、簡単にインストールできます。
- BeOSおよびOS/2の場合は、それぞれ、BeBits.com とHobbes OS/2 archive を探してみることをお勧めします。MacOSの場合、David MertzはMacSSH を使用していますが、Nifty Telnet 1.1 SSH については特にこれといった評価はありません。MacOSのリンクについてはFreeSSH のサイトを調べてください。
VNCの参考文献
-
ただし、VNCの移植に関するページは完全に最新の情報ではありません。特定のプラットフォーム用のVNCの最新で最高のバージョンについては、BeOS、またはOS/2 WarpやeComStation などのような、そのプラットフォームに対する標準のアプリケーション・リポジトリーを調べる方がいいでしょう。
- 場合によっては、VNCviewerのJavaバージョンを使用したくても、マシンにあるのがJavaランタイム環境だけで、
javac 開発ツールがないことがあります。David Mertzは、バイト・コードにコンパイルした
.jar ファイルと.class ファイルを作成しました (サポートはしていません)。試してみてください。
著者について  | | | David Mertz が、多岐にわたる経歴の中で、自分に与えられた役割を超える貢献をしてきたことは、あまねく知られています。その多くは、アカデミックな「ポストモダン」哲学の分野で行なわれています (しかし一方では、この記事も複数レベルの記述的「地位」を占めています)。David にはmertz@gnosis.cx で連絡することができ、また彼が熱心に研究している対象は、http://gnosis.cx/publish/ でうかがうことができます。このコラムに限らず、過去または将来のコラムに関するご意見やご希望も歓迎するそうです。 |
記事の評価
| 
