Product SiteDocumentation Site

9.2. リモートログイン

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

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

SSH (Secure SHell) プロトコルは安全性と信頼性を念頭に置いて設計されました。SSH を使う接続は安全です: 通信相手は認証され、交換されるデータは全て暗号化されます。
さらに SSH は 2 種類のファイル転送サービスを提供します。scpcp のように使えるコマンドラインツールです。ただし、他のマシンへのパスを表記するには、パスの前にそのマシンの名前とコロンを付ける点が異なります。
$ 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 を作成しました。
OpenSSH は 2 つのパッケージに分解されています: クライアント部分は openssh-client パッケージ、サーバ部分は openssh-server パッケージです。ssh メタパッケージは両方のパッケージに依存し、両方のインストールが簡単に (apt-get 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 はグラフィカルセッションではデフォルトでこれを有効化しますが、/etc/X11/Xsession.options を変更すれば無効化することも可能です。コンソールセッションでは、eval $(ssh-agent) を使って手作業で開始できます。

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

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

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

-R-L オプションを使うと、ssh が 2 台のマシン間で「暗号化トンネル」を作成することが可能です。ローカル TCP ポート (傍注BACK TO BASICS TCP/UDP参照) をリモートのマシンに安全に転送したりその逆も可能です。
ssh -L 8000:server:25 intermediaryintermediary ホストと SSH セッションを確立し、ローカルの ssh がローカルのポート 8000 番をリッスンします (図9.2「SSH を使ったローカルポートの転送」参照)。 intermediaryssh は、ローカルのポート 8000 番を経由して接続が開始されたら、intermediary コンピュータから server のポート 25 番に接続し、ローカルから server への接続を中継します。
ssh -R 8000:server:25 intermediaryintermediary コンピュータとの SSH セッションを確立し、intermediarysshintermediary のポート 8000 番をリッスンします (図9.3「SSH を使ったリモートポートの転送」参照)。ローカルの ssh は、intermediary のポート 8000 番を経由して接続が開始されたら、ローカルマシンから server のポート 25 番に接続し、intermediary から server への接続を中継します。
どちらの場合も server ホストのポート 25 番に対して、ローカルマシンと intermediary マシンの間に確立した SSH トンネルを通り抜けて、接続します。最初の例の場合、トンネルの入口はローカルのポート 8000 番で、データはまずintermediary マシンを目指し、その後に「公開」ネットワークを経由して server に向かいます。2 番目の例の場合、トンネルの入口と出口が逆になります; トンネルの入口は intermediary マシンのポート 8000 番で、出口はローカルホストにあります。出口から出たデータは server に向かいます。現実的な話をすると、ここで言うサーバは通常、ローカルマシンまたは intermediary です。このようにして SSH は端から端までの接続を保護します。
SSH を使ったローカルポートの転送

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

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

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

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

VNC (Virtual Network Computing) を使うとグラフィカルデスクトップにリモートからアクセスすることが可能になります。
このツールは技術支援に使われることが多いです: 管理者はユーザが直面しているエラーを見ることが可能で、ユーザの側にいなくても正しい行動の仕方をユーザに示すことが可能です。
最初に、ユーザは自分のセッションの権限を共有しなければいけません。GNOME と KDE グラフィカルデスクトップ環境には、それぞれ vinokrfb が含まれています。これらは VNC を通じて既存のセッションを共有する事が可能になるグラフィカルインターフェイス提供します (GNOME アプリケーションリストか KDE メニューの中にあるデスクトップ共有がこのプログラムです)。他のグラフィカルデスクトップ環境に対しては、(同名の Debian パッケージの提供する) x11vnc コマンドがその代わりになります; 明確なアイコンを使って、ユーザがこれを使えるようにすることが可能です。
VNC がグラフィカルセッションを利用可能にしたら、管理者は VNC クライアントでセッションに接続しなければいけません。VNC クライアントとして、GNOME には vinagreremmina が、KDE には krdc (KInternetリモートデスクトップクライアント) が用意されています。コマンドラインを使う他の VNC クライアントもあります。例えば、同名の Debian パッケージが提供するxvnc4viewer などです。一旦セッションに接続したら、管理者は、何が起きているか見て、リモートでマシンの作業を行い、ユーザにその様子を見せることが可能です。
また 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
入ってくる接続をディスプレイマネージャに転送することにより、認証の問題が解決されます。なぜなら、ローカルアカウントを持つユーザだけが gdm (または同等の kdmxdm など) のログイン画面を突破できるからです。このやり方は (サーバの性能が十分高いなら) なんの問題も無く複数の同時ログインを許すため、完全なデスクトップをモバイルユーザに対して (またはシンクライアントとして設定された非力なデスクトップシステムに対して) 提供するという用途にも応用できます。ユーザは単純に vncviewer server:50 でサーバの画面にログインするだけです。なぜなら、使われているポートは 5950 番だからです。