9.2. リモートログイン

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

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

SSH (Secure SHell) プロトコルは安全性と信頼性を念頭に置いて設計されました。SSH を使う接続は安全です。つまり、通信相手は認証され、交換されるデータはすべて暗号化されます。

VOCABULARY 認証、暗号化

When you need to give a client the ability to conduct or trigger actions on a server, security is important. You must ensure the identity of the client; this is authentication. This identity usually consists of a password or passphrase that must be kept secret, or any other client could it. This is the purpose of encryption, which is a form of encoding that allows two systems to communicate confidential information on a public channel while protecting it from being readable to others.

認証と暗号化はしばしば一緒に言及されます。なぜなら両者は同時に使われることが多く、よく似た数学的概念を基に実行されることが多いからです。

さらに SSH は 2 種類のファイル転送サービスを提供します。scp は cp のように使えるコマンドラインツールです。ただし、他のマシンへのパスを表記するにはパスの前にそのマシンの名前とコロンを付ける点が 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 を作成しました。

BACK TO BASICS フォーク

ソフトウェアの分野で「フォーク」とは、既存のプロジェクトのクローンとして始まった新しいプロジェクトを意味しており、既存のプロジェクトの対抗馬です。通常、両方のソフトウェアは新しい開発という観点ですぐに別のものになっていきます。フォークは開発チーム内の意見の不一致によって起こることが多いです。

プロジェクトをフォークするという選択肢はフリーソフトウェアの本質そのものから生じた直接的な結果です。フリーソフトウェアとしてのプロジェクトの存続を可能にするための (たとえばライセンスが変更された場合などの) フォークは健全な出来事です。技術的および個人的な意見の不一致によって起こるフォークは通常人的資源の無駄です。従って別の解決策が望まれます。過去にフォークした 2 つのプロジェクトの合併はいまだ前例がありません。

OpenSSH is split into two packages: the client part is in the openssh-client package, and the server is in the openssh-server package. The ssh meta-package depends on both parts and facilitates installation of both (apt install ssh), while the task-ssh-server, often chosen during the initial installation, depends on the server package only.

9.2.1.1. 鍵認証方式

リモートサーバはユーザを認証するために SSH でログインする人に対して毎回パスワードを尋ねます。これは、接続を自動化したい場合や SSH 経由で頻繁に接続を行うツールを使う場合に問題です。このため、SSH は鍵認証システムを提供しています。

The user generates a key pair on the client machine with ssh-keygen -t rsa; the so generated public key is stored in ~/.ssh/id_rsa.pub, while the corresponding private key is stored in ~/.ssh/id_rsa. The user can then use ssh-copy-id server to add their public key to the ~/.ssh/authorized_keys file on the server, or, if SSH access hasn't been enabled yet, they have to ask the administrator to add their key manually.

If the private key was not protected with a “passphrase” at the time of its creation, all subsequent logins on the server will work without a password. Otherwise, the private key must be decrypted each time by entering the passphrase. Fortunately, ssh-agent allows us to keep private keys in memory to not have to regularly re-enter the password. For this, you simply use ssh-add (once per work session) provided that the session is already associated with a functional instance of ssh-agent. Debian activates it by default in graphical sessions, but this can be deactivated by changing /etc/X11/Xsession.options and commenting out use-ssh-agent. For a console session, you can manually start the agent with eval $(ssh-agent).

SECURITY 秘密鍵の保護

秘密鍵を持っていれば、誰でも対応する公開鍵を登録したアカウントにログインすることが可能です。このため、秘密鍵の利用は「パスフレーズ」で保護されています。秘密鍵ファイル (たとえば ~/.ssh/id_rsa) のコピーを不正に入手した人が秘密鍵を使うためには、パスフレーズを知らなければいけません。しかしながら、「パスフレーズ」による追加的な保護は堅固なものではありません。秘密鍵ファイルが不正に使われていると感じたなら、その秘密鍵に対応する公開鍵をインストールしたコンピュータでその公開鍵の使用を停止し (authorized_keys ファイルから公開鍵を削除し)、新しく生成した鍵で公開鍵を置き換えるのが最良の対応策です。

CULTURE Debian Etch における OpenSSL の脆弱性

The OpenSSL library, as initially provided in Debian Etch, had a serious problem in its random number generator (RNG). Indeed, the Debian maintainer had made a change so that applications using it would no longer generate warnings when analyzed by memory testing tools like valgrind. Unfortunately, this change also meant that the RNG was employing only one source of entropy corresponding to the process number (PID) whose 32,000 possible values do not offer enough randomness.

→ https://www.debian.org/security/2008/dsa-1571

具体的に言えば、OpenSSL を使って鍵を生成した場合、生成された鍵は常に数十万 (鍵長種数の 32,000 倍) の既知の範囲内にある鍵のうちの 1 つになります。この脆弱性は、たとえば OpenVPN など数多くのアプリケーションが使う SSH 鍵、SSL 鍵、X.509 証明書に影響をおよぼしました。クラッカーは全種類の鍵を試すだけで不正アクセスを実行することが可能でした。この問題の影響を減らす目的で、SSH デーモンは openssh-blacklist と openssh-blacklist-extra パッケージにリストされている問題のある鍵を拒否するように変更されました。さらに、ssh-vulnkey コマンドを使えば、システム内からこの脆弱性の影響を受けているかもしれない鍵を識別することが可能です。

この出来事をいっそう詳しく調べると、これは OpenSSL プロジェクト内と Debian パッケージメンテナ双方にあった多数の (小さな) 問題の結果であるということが、明らかになります。OpenSSL のように広く使われるライブラリは (修正せずとも) valgrind でテストした時に警告を出すべきではありません。さらに、コード (特に RNG と同様に慎重に取り扱われるべき部分) はこのような誤解を避ける目的で詳しい注釈を付けられるべきです。Debian 側について言えば、メンテナは OpenSSL 開発者から修正に対する検証を受けることを望んでいながら、修正の検証に必要なパッチを OpenSSL 開発者に提供することもせずに自分の修正について簡単に説明しただけで、Debian 内における自分の役割を口にすることもしませんでした。そして最後に、メンテナンス方針が最適なものではありませんでした。具体的に言えば、元のコードに対して行った修正が文書中で明らかにされず、さらにすべての修正は Subversion リポジトリに効果的に保存されていましたが、最終的にすべての修正はソースパッケージの作成中に 1 つのパッチにまとめられていました。

It is difficult under such conditions to find the corrective measures to prevent such incidents from recurring. The lesson to be learned here is that every divergence Debian introduces to upstream software must be justified, documented, submitted to the upstream project when possible, and widely publicized. It is from this perspective that the new source package format (“3.0 (quilt)”) and the Debian sources webservice were developed.

→ https://sources.debian.org

9.2.1.2. Cert-Based Authentication

SSH keys cannot just be protected by a password (or not). An often unknown feature is that they can also be signed via certificate, both the host as well as the client keys. This approach comes with several advantages. Instead of maintaining an authorized_keys file per user as described in the previous section, the SSH server can be configured to trust all client keys signed by the same certificate (see also 第 10.2.2 節「公開鍵基盤、easy-rsa」) by using the TrustedUserCAKeys and HostCertificate directives in /etc/ssh/sshd_config.

TrustedUserCAKeys /etc/ssh/ssh_users_ca.pub

HostKey /etc/ssh/ssh_host_ecdsa_key
HostCertificate /etc/ssh/ssh_host_ecdsa_key-cert.pub

Vice-versa the clients can also be configured to trust the host key signed by the same authority, making it easier to maintain the known_hosts file (even system wide via /etc/ssh/known_hosts).

@cert-authority *.falcot.com ssh-rsa AAAA[..]

Both, public key and certificate authentication, can be used alongside each other.

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

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

GOING FURTHER Magic cookies in .Xauthority

When a user connects via SSH and starts a remote X11 session, a so-called magic cookie is created and stored in the .Xauthority file in the user's home directory that initiated the connection. This cookie is used by xauth to authenticate the user during the X session. If the user impersonates another user on the system, e.g. using su or sudo, then the cookie is not copied automatically to the target user and the X server will refuse to start graphical applications under the target user's context. You will have to copy the magic cookie into the target user's home directory (by exporting and re-importing the cookie via xauth) to allow another user to start graphical programs as well during the X session.

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

ssh の -R と -L オプションを使うと、ssh が 2 台のマシン間で「暗号化トンネル」を作成することが可能です。「暗号化トンネル」を使えば、ローカル TCP ポート (補注「BACK TO BASICS TCP/UDP」を参照してください) をリモートのマシンに安全に転送したりその逆を行うことも可能です。

VOCABULARY トンネル

インターネットとインターネットに接続されている多くの LAN はパケットモードで動作しており、接続モードで動作していません。これは、一方のコンピュータから他方のコンピュータに向かって送信されたパケットは、宛先への経路を見つけるために複数の中間ルータで足止めされることを意味しています。とは言っても、接続モードを模倣することも可能です。接続モードではストリームを普通の IP パケットの中にカプセル化します。これらのパケットは通常の経路を通過しますが、ストリームは宛先を変えられることなく再構成されます。これは道路のトンネルにかけて「トンネル」と呼ばれています。道路のトンネルでは車両が入口 (入力) から出口 (出力) まで交差点に遭遇することなくまっすぐ進むのに対し、地上の経路を使うと車両は交差点を通過したり右折左折を繰り返しながら目的地まで進むことになります。

トンネルに暗号化機能を追加することが可能です。すなわち、トンネルの中を流れるストリームは外から認識できませんが、トンネルの出口で復号化された形で返されます。

ssh -L 8000:server:25 intermediary を使うことで、ローカルの ssh に intermediary との SSH セッションを確立させ、ローカルの ssh にローカルのポート 8000 番をリッスンさせます (図 9.3「SSH を使ったローカルポートの転送」を参照してください)。ローカルのポート 8000 番を経由して接続が開始されたら、intermediary の ssh は intermediary から server のポート 25 番に接続し、ローカルから server への接続を中継します。

ssh -R 8000:server:25 intermediary を使うことで、ローカルの ssh に intermediary との SSH セッションを確立させ、intermediary の ssh に intermediary のポート 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 は端から端までの接続を保護します。

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

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

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

VNC (Virtual Network Computing) を使うとグラフィカルデスクトップにリモートからアクセスすることが可能になります。

VNC は技術支援に使われることが多いです。なぜなら、管理者はユーザが直面しているエラーを見ることが可能で、ユーザの側にいなくても正しい行動の仕方をユーザに示すことが可能だからです。

First, the user must authorize sharing their session. The GNOME graphical desktop environment includes that option via Settings → Sharing (contrary to previous versions of Debian, where the user had to install and run vino). For this to work network-manager must be managing the network used (e.g. enable the managed mode for devices handled by ifupdown in /etc/NetworkManager/NetworkManager.conf). KDE Plasma still requires using krfb to allow sharing an existing session over VNC. For other graphical desktop environments, the x11vnc or tightvncserver commands (from the Debian packages of the same name) or tigervncserver (tigervnc-standalone-server) serve the same purpose and provide the vnc-server virtual package; you can make either of them available to the user with an explicit menu or desktop entry.

When the graphical session is made available by VNC, the administrator must connect to it with a VNC client. GNOME has vinagre and remmina for that, while the KDE project provides krdc (in the menu at K → Internet → Remote Desktop Client). There are other VNC clients that use the command line, such as xtightvncviewer from the homonym package or xtigervncviewer from the tigervnc-viewer Debian package. Once connected, the administrator can see what is going on, work on the machine remotely, and show the user how to proceed.

SECURITY VNC over SSH

VNC で接続したいけれども、データを平文でネットワークに流したくない場合、SSH トンネルでデータをカプセル化することが可能です (第 9.2.1.4 節「ポート転送を使った暗号化トンネルの作成」を参照してください)。この時知っておかなければいけない点は、デフォルトで VNC は最初の画面 (「localhost:0」と呼ばれます) にポート 5900 番、2 番目の画面 (「localhost:1」と呼ばれます) にポート 5901 番を使うという点だけです。

ssh -L localhost:5901:localhost:5900 -N -T machine コマンドを使うことで、localhost インターフェースのポート 5901 番と machine のポート 5900 番の間にトンネルが作られます。最初の「localhost」はローカルのインターフェースのみをリッスンするように SSH を制限します。2 番目の「localhost」は「localhost:5901」に入ってきたネットワークトラフィックを受け取るリモート側のインターフェースを表します。そんなわけで、vncviewer localhost:1 はローカルの名前を使っているにも関わらず VNC クライアントをリモートの画面に接続します。

VNC セッションを閉じたら、対応する SSH セッションを終了してトンネルを閉じることも忘れないでください。