SSHとは ― 接続の流れと公開鍵認証

SSH（Secure Shell）は、離れたコンピュータをネットワーク越しに安全に操作するためのプロトコルです。サーバはTCPの22番で待ち受け、通信の暗号化・サーバの確認・利用者の確認の3つを接続のたびに行います。

SSHは、3つの部分を積み重ねた構成です。1つ目は暗号化とサーバの確認、2つ目は利用者の確認を受け持ち、3つ目は端末の操作や転送を運びます。

同じ遠隔操作のプロトコルであるTELNETとの違いは、暗号化の有無です。TELNETとのポート番号の比較は、FTP・TELNET・NTPの記事にあります。以下では、接続の流れと暗号の鍵の仕組みを図で説明します。

SSHの接続は、6段階で進みます。段階ごとに、通信の暗号化・サーバの確認・利用者の確認がどう変わるかを、次の図で確かめられます。

ステップ3の共通の秘密からは、通信を暗号化する鍵と、改ざんを検知する鍵が作られます。通信の暗号化には、共通鍵暗号方式を使います。公開鍵暗号方式は、共通の秘密を作る鍵交換と、サーバと利用者の確認に使います。この分担は、HTTPSにも共通する考え方です。

ステップ4で暗号化が始まる前の通信は、平文です。ただし、ステップ3で流れるのは計算用の値とホスト鍵と署名で、共通の秘密そのものは流れません。

サーバがTCPの22番で待ち受けているかは、netstat・ss・digの記事の方法で確かめられます。

ホスト鍵は、サーバが自分を証明するために持つ鍵のペアです。サーバは秘密鍵を自分だけで持ち、公開鍵をクライアントに渡します。サーバはステップ3で秘密鍵で署名を作り、クライアントは公開鍵でその署名が正しいことを確かめます。

ただし、署名が正しいだけでは、その公開鍵が目的のサーバのものかどうかは分かりません。偽のサーバも、自分の鍵のペアで署名を作れるからです。そのためクライアントは、目的のサーバの公開鍵を、あらかじめ知っている必要があります。

RFC 4251は、その方法を2つ挙げています。1つは、クライアントの手元に、ホスト名と公開鍵の対応表を持つ方法です。もう1つは、信頼できる認証局がその対応を保証する方法です。

OpenSSHの標準的な使い方は前者で、対応表は利用者のホームディレクトリの ~/.ssh/known_hosts に保存されます。初めて接続するサーバは、この表に載っていません。

$ ssh user@example.com

指紋は、公開鍵から計算した短い文字列です。表示の細部は、OpenSSHのバージョンで少し違います。

この時点で、通信はすでに暗号化されています。ただ、相手が本物かどうかは、yesと答える人の判断にかかっています。RFC 4251によると、この確認を省いた場合、盗聴は防げますが、通信の途中に入り込んで双方になりすます中間者攻撃には弱くなります。

ホスト鍵が変わったときの警告

OpenSSHは、記録と違う鍵を示されると「WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!」と警告し、既定の設定では接続を中止します。

原因には、中間者攻撃の場合と、サーバのホスト鍵が正当に変わっただけの場合があります。警告の文面は、システム管理者への連絡を求めています。鍵が正当に変わったと確かめられたら、known_hosts の古い記録を直してから接続し直します。

サーバが利用者を確認する方法には、パスワード認証と公開鍵認証があります。RFC 4252では、公開鍵認証はすべての実装が対応しなければならない方法で、パスワード認証は対応が望ましい方法とされています。

パスワード認証は、パスワードをサーバに送る

パスワード認証では、クライアントがパスワードをサーバに送ります。暗号化された通信の中で送るので途中では読まれませんが、パスワードそのものがサーバに届きます。

サーバが乗っ取られていると、そこでパスワードが読み取られます。RFC 4251も、パスワード認証はサーバの安全を前提にしていると指摘しています。

公開鍵認証は、秘密鍵で作った署名を送る

公開鍵認証では、利用者があらかじめ鍵のペアを作り、公開鍵だけをサーバに登録します。OpenSSHでは、サーバ側の ~/.ssh/authorized_keys に公開鍵を1行ずつ書きます。秘密鍵は、利用者の手元に残します。

ログインのとき、クライアントは秘密鍵で署名を作って送り、サーバは登録された公開鍵で署名を検証します。秘密鍵を持っていることが、そのまま本人の証明になります。

署名の対象には、ステップ3でできた、この接続だけのセッション識別子が含まれます。秘密鍵は暗号化して保存することが多く、署名を作るときに利用者がパスフレーズを入力します。秘密鍵のファイルを盗まれると持ち主になりすまされるので、取り扱いに注意が必要です。

公開鍵認証は、サーバの安全性を前提にしません。サーバが乗っ取られても、読み取れるのは公開鍵だけです。暗号化はどちらの認証でも使われるので、違いはサーバに何が届くかです。

SSHには、役割の違う鍵のペアが2組あります。どちらも公開鍵と秘密鍵の組ですが、確かめる向きが逆です。

ホスト鍵は、クライアントが「この相手は本物のサーバか」を確かめるための鍵です。利用者の鍵は、サーバが「この人は登録された利用者か」を確かめるための鍵です。2組とも、通信を暗号化する鍵とは別のものです。暗号化の鍵は、ステップ3の共通の秘密から作られます。

SSHの1本の接続には、チャネルという論理的な通信路をいくつも束ねられます。端末の操作も、転送された通信も、それぞれ別のチャネルとして1本の接続を共有します。

ポートフォワーディング：別の通信をSSHの中に通す

ポートフォワーディングは、片側のポートに届いた通信を、SSHの暗号化された接続に乗せて、反対側から別の宛先へ渡す機能です。手元のポートを入口にする場合は、-L で指定します。自分のPCのターミナルで次のように入力すると、PCの8080番がサーバの80番につながります。

$ ssh -L 8080:localhost:80 user@203.0.113.50
# 自分のPCの8080番に届いた通信が、SSHの接続の中を通ってサーバへ運ばれます。
# サーバは、その通信を自分自身（localhost）の80番へ渡します。

ブラウザで localhost:8080 を開くと、203.0.113.50 のサーバの80番にあるWebページが、暗号化された通信で届きます。Web以外の通信でも、仕組みは同じです。転送される通信は、SSHの接続の中を通る間、暗号化されます。外から直接入れない内部のサーバへ接続するときの使い方は、踏み台サーバの記事で説明しています。

この名前は、ルータで設定するポート開放の別名と同じですが、中身は別のものです。ポート開放はルータの変換テーブルの設定で、SSHのポートフォワーディングはSSHの接続を使う機能です。

RFC 4251は、この転送がファイアウォールに検知されずに通り抜ける通信にもなりうると注意し、管理者が転送を制御できる仕組みを実装に求めています。ファイアウォールが通す通信を絞っていても、許可されたSSHの通信の中に別の通信が隠れることがあるためです。

SFTP：SSHの上でファイルを運ぶ

SFTPは、SSHの暗号化された接続の上でファイルを転送するプロトコルです。OpenSSHのsftpは、すべての操作をSSHの通信路の上で行います。FTPとの違いは、FTP・TELNET・NTPの記事で比べています。

Ansibleのような自動化ツールも、SSHなどの既存の接続手段で機器を操作します。この使われ方は、ネットワーク自動化の記事で説明しています。

• RFC 4251 The Secure Shell (SSH) Protocol Architecture：全体の構成、ホスト鍵の信頼モデル
• RFC 4252 The Secure Shell (SSH) Authentication Protocol：パスワード認証と公開鍵認証
• RFC 4253 The Secure Shell (SSH) Transport Layer Protocol：22番、方式の合意、鍵交換
• RFC 4254 The Secure Shell (SSH) Connection Protocol：チャネルとポートの転送
• OpenSSH ssh(1) マニュアル：known_hosts、authorized_keys、-L
• OpenSSH sftp(1) マニュアル：SFTPとSSHの関係
• OpenSSH sshconnect.c：初回接続の確認文と警告の文面