Product SiteDocumentation Site

9.2. リモートログイン

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

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

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

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

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

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

ssh-R-L オプションを使うと、ssh が 2 台のマシン間で「暗号化トンネル」を作成することが可能です。「暗号化トンネル」を使えば、ローカル TCP ポート (補注BACK TO BASICS TCP/UDP」を参照してください) をリモートのマシンに安全に転送したりその逆を行うことも可能です。
ssh -L 8000:server:25 intermediary を使うことで、ローカルの sshintermediary との SSH セッションを確立させ、ローカルの ssh にローカルのポート 8000 番をリッスンさせます (図 9.3「SSH を使ったローカルポートの転送」を参照してください)。ローカルのポート 8000 番を経由して接続が開始されたら、intermediarysshintermediary から server のポート 25 番に接続し、ローカルから server への接続を中継します。
ssh -R 8000:server:25 intermediary を使うことで、ローカルの sshintermediary との SSH セッションを確立させ、intermediarysshintermediary のポート 8000 番をリッスンさせます (図 9.4「SSH を使ったリモートポートの転送」を参照してください)。intermediary のポート 8000 番を経由して接続が開始されたら、ローカルの ssh はローカルから server のポート 25 番に接続し、intermediary から server への接続を中継します。
どちらの場合も、ローカルと intermediary の間に確立した SSH トンネルを介して、server のポート 25 番に接続します。最初の例の場合、トンネルの入口はローカルのポート 8000 番で、データはまず intermediary を目指し、その後に「公開」ネットワークを経由して server に向かいます。2 番目の例の場合、トンネルの入口と出口が逆になります。トンネルの入口は intermediary のポート 8000 番で、出口はローカルにあります。出口から出たデータは server に向かいます。現実的な話をすると、ここで使われている 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 パッケージに含まれます) を使います。さらに、管理者はわかりやすいアイコンを作ってユーザが x11vnc を実行できるようにすることが可能です。
VNC がグラフィカルセッションを利用できるようにしたら、管理者は VNC クライアントでセッションに接続しなければいけません。VNC クライアントとして、GNOME には vinagreremmina が、KDE には krdc (Kインターネットリモートデスクトップクライアント) が用意されています。コマンドラインを使う他の VNC クライアントもあります。たとえば、xvnc4viewer (同名の Debian パッケージに含まれます) などです。ひとたびセッションに接続したら、管理者は何が起きているか確認し、リモートでマシンの作業を行い、ユーザにその様子を見せることが可能です。
また、モバイルユーザや会社幹部のような自分が仕事場で使っているのとよく似たリモートデスクトップにアクセスするために時々自宅からログインする必要があるユーザにとって、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 番だからです。