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 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 サーバ上に表示され、すべてのセッション (入力と表示) は安全です。この機能により、リモートアプリケーションがローカルシステムに干渉することになるため、この機能はデフォルトで無効化されています。この機能を有効化するには、SSH サーバの設定ファイル (/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.3「SSH を使ったローカルポートの転送」を参照してください)。intermediaryssh は、ローカルのポート 8000 番を経由して接続が開始されたら、intermediary コンピュータから server のポート 25 番に接続し、ローカルから server への接続を中継します。
ssh -R 8000:server:25 intermediaryintermediary コンピュータとの SSH セッションを確立し、intermediarysshintermediary のポート 8000 番をリッスンします (図 9.4「SSH を使ったリモートポートの転送」を参照してください)。ローカルの ssh は、intermediary のポート 8000 番を経由して接続が開始されたら、ローカルマシンから server のポート 25 番に接続し、intermediary から server への接続を中継します。
どちらの場合も server ホストのポート 25 番に対して、ローカルマシンと intermediary マシンの間に確立した SSH トンネルを通り抜けて、接続します。最初の例の場合、トンネルの入口はローカルのポート 8000 番で、データはまず intermediary マシンを目指し、その後に「公開」ネットワークを経由して server に向かいます。2 番目の例の場合、トンネルの入口と出口が逆になります。従って、トンネルの入口は intermediary マシンのポート 8000 番で、出口はローカルホストにあります。出口から出たデータは server に向かいます。現実的な話をすると、ここで言うサーバは通常、ローカルマシンまたは intermediary です。このようにして SSH は端から端までの接続を保護します。
SSH を使ったローカルポートの転送

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

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

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

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

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