Linuxの暗号化によるデータの保護

暗号化によるデータの保護

この主題は、公開鍵暗号（非対称暗号）という1つの技術が、Linuxシステムの中で「OpenSSH（リモートログイン・ファイル転送）」と「GnuPG（ファイルの暗号化・署名）」という2つの異なる場面でどう使われているかを扱います。

公開鍵暗号では、数学的に対になった公開鍵と秘密鍵の鍵ペアを使います。

• 公開鍵は誰に渡しても構いません（名前のとおり公開してよい鍵です）。
• 秘密鍵は本人だけが保持し、絶対に他人に渡してはいけません。

用途によって、鍵ペアの使い方は次のように変わります。

• 暗号化・復号：公開鍵で暗号化したデータは、対応する秘密鍵でしか復号できません。「秘密鍵の持ち主だけが読める」データを作れます。
• 署名・検証：秘密鍵で作成した署名は、対応する公開鍵で検証できます。「対応する秘密鍵の持ち主が作成した（改ざんされていない）」ことを確認できます。公開鍵と本人の対応付けを信頼できる方法で確認している場合には、その本人による作成も確認できます。

OpenSSHでは公開鍵暗号が主にサーバー・ユーザーの認証や鍵交換に使われ、実際の通信データは鍵交換後に共有した共通鍵による対称暗号で暗号化されます。GnuPGは主にファイル・メッセージの暗号化と署名にこの仕組みを使います。それぞれの具体的な使い方を見ていきます。

OpenSSHの鍵ペアと認証

ssh-keygen：鍵ペアの生成

ssh-keygenは、SSHで使う公開鍵・秘密鍵の鍵ペアを生成するコマンドです。-tオプションで鍵のアルゴリズムを指定します。

ssh-keygen -t ed25519

• -t rsa：RSAアルゴリズム。-bオプションでビット数を指定できます（現在のssh-keygenの既定値は3072ビット、最小1024ビット）^{RSAの推奨ビット数・既定値はOpenSSHのバージョンによって変わってきた経緯があります（かつては2048ビットが既定でした）。「RSAは常に2048ビット」と固定的に覚えず、必要に応じて現在の既定値を確認してください。[1]}。
• -t ecdsa：ECDSA（楕円曲線DSA）アルゴリズム。-bで256・384・521のいずれかを指定します（512ではなく521ビットである点に注意してください。これはNISTの標準曲線P-521に対応した値です）。
• -t ed25519：ED25519アルゴリズム。鍵長は固定のため-bオプションは無視されます。
• -t dsa：DSAアルゴリズム。後述のとおり、現在のOpenSSHでは扱いが大きく変わっている点に注意が必要です。

-tを省略してssh-keygenとだけ実行した場合、現在のOpenSSHではED25519の鍵ペアが生成されます^{この既定値はOpenSSHのバージョンによって異なります。長らくRSAが既定でしたが、現在のOpenSSHのマニュアルでは「引数無しで実行するとED25519の鍵を生成する」と明記されています。導入されているOpenSSHのバージョンによっては、既定がRSAのままの場合もあります。[2]}。

DSAの現在の扱いについて

DSAは、公式の出題範囲・関連ファイル一覧（~/.ssh/id_dsa、/etc/ssh/ssh_host_dsa_keyなど）に今も名前が残っていますが、実際のOpenSSHでの扱いは大きく後退しています。

• OpenSSH 7.0（2015年）：SSHで使われるDSA鍵（ssh-dss）を既定で無効化しました。SSHのDSA鍵は1024ビットに固定されていたことなどが背景にあります（設定を変更すれば利用は可能でした）。
• OpenSSH 10.0（2025年）：DSA鍵のサポート自体を完全に削除しました。

そのため、OpenSSH 10.0以降では、新たにDSA鍵を生成したり、DSA鍵で認証したりすることはできません。OpenSSH 7.0以降10.0未満では、DSA鍵の生成自体は可能な場合がありますが、ssh-dssによる認証は既定で無効です。「id_dsa・ssh_host_dsa_keyというファイル名が何のためのものかを知っている」ことと、「OpenSSHのDSAは現在では非推奨・廃止されたアルゴリズムであると理解している」ことの両方が、試験対策上のポイントになります^{非常に古いディストリビューション・古いバージョンのOpenSSHが稼働している環境では、今でもDSA鍵が有効な場合があります。「DSAは絶対にどの環境でも使えない」という意味ではなく、現在の主要なOpenSSHのリリースでは廃止済み、という理解が正確です。[3]}。

ユーザーの鍵ファイル：~/.ssh/id_*

ssh-keygenで生成した鍵ペアは、既定では次のファイル名でホームディレクトリの~/.ssh/以下に保存されます。

これらはユーザー自身の身元を証明するための鍵です。秘密鍵ファイルは所有者本人以外がアクセスできないパーミッション（600など）である必要があり、sshコマンドは秘密鍵ファイルのパーミッションが緩すぎる場合、その秘密鍵の使用を拒否します。公開鍵ファイル（.pubが付くほう）は、後述のauthorized_keysに登録することで、パスワードの代わりにこの鍵ペアでログインできるようになります。

サーバーのホスト鍵：/etc/ssh/ssh_host_*_key

/etc/ssh/以下のホスト鍵には、ssh_host_rsa_key・ssh_host_dsa_key・ssh_host_ecdsa_key・ssh_host_ed25519_key（それぞれに対応する.pubファイル）というファイル名があります。ただし、実際に生成されるホスト鍵の種類はディストリビューションの設定やOpenSSHのバージョンに依存し、すべてのファイルが存在するとは限りません。特にOpenSSH 10.0以降ではDSAホスト鍵はサポートされません。これらはユーザーの鍵ではなく、SSHサーバー（sshd）自身の身元を証明するための鍵で、OSのインストール時やsshdの初回起動時に自動生成されるのが一般的です。

• ユーザー鍵（~/.ssh/id_*）：クライアント側で、「自分が誰であるか」をサーバーに証明するために使います。
• ホスト鍵（/etc/ssh/ssh_host_*_key）：サーバー側で、「接続先が本当にそのサーバーであるか」をクライアントに証明するために使います。

この2種類の鍵は、ファイル名が似ているために混同されがちですが、「誰が」「何を証明するために」使う鍵かという役割がまったく異なります。試験でもこの違いを問う出題が見られるポイントです。

authorized_keysとknown_hosts

ホスト鍵・ユーザー鍵と関連して、次の2つのファイルもそれぞれ異なる側（サーバー側／クライアント側）で使われます。

known_hostsにホスト鍵が記録された状態で、サーバーのホスト鍵が変わっていた場合、SSHクライアントは強い警告（中間者攻撃の可能性を示すメッセージ）を表示し、既定の設定では接続を拒否します。これは、正規のサーバー再構築時にホスト鍵が再生成された場合にも起こり得るため、警告が出た際は「本当にサーバー側の正当な変更か」を確認したうえで対応する必要があります^{~/.ssh/known_hostsはユーザーごとの記録、/etc/ssh/ssh_known_hostsはシステム全体で共有する記録という違いがあります。どちらか一方だけが存在する環境も、両方使われている環境もあります。[4]}。

ssh-agentとssh-add

パスフレーズ（秘密鍵自体を保護するパスワード）を設定した秘密鍵は、SSH接続のたびにパスフレーズの入力を求められます。これを毎回入力する手間を省くための仕組みがssh-agentとssh-addです。

• ssh-agent：バックグラウンドで動作し、復号済みの秘密鍵をメモリ上に保持しておくためのプログラムです。
• ssh-add：手元の秘密鍵ファイルをssh-agentに登録するコマンドです。パスフレーズの入力はこのssh-add実行時の1回だけで済み、以降は同じエージェントを利用する間、sshコマンド実行時にパスフレーズを聞かれなくなります。

ssh-agentの終了時期は起動方法やセッション管理方式に依存します。シェルから起動した場合はそのシェルの終了に伴って終了することがありますが、デスクトップセッションやsystemdのユーザーサービスなどで起動されている場合は、シェルを終了しても動作を継続することがあります。保持していた鍵の情報が失われても、ディスク上の秘密鍵ファイル自体が変更されるわけではありません。

SSHポートフォワーディング（ポートトンネル）

SSH接続の暗号化された通信路（トンネル）を使って、SSH以外の通信を中継させる機能がポートフォワーディング（ポートトンネル）です。

• ローカルフォワーディング（ssh -L ローカルポート:転送先ホスト:転送先ポート 接続先）：手元のマシンの指定ポートへの接続を、SSH接続先経由で、さらにその先の転送先ホスト:転送先ポートへ転送します。社内ネットワークなど、直接は到達できない場所にあるサービスに、踏み台のSSHサーバー経由でアクセスしたい場合に使います。
• リモートフォワーディング（ssh -R リモートポート:転送先ホスト:転送先ポート 接続先）：向きが逆で、SSH接続先側の指定ポートへの接続を、手元のマシン経由で転送先ホスト:転送先ポートへ転送します。
• ダイナミックフォワーディング（ssh -D ローカルポート 接続先）：手元のマシンにSOCKSプロキシを立て、そのプロキシ経由の通信をSSH接続先から任意の宛先へ中継します。あらかじめ転送先を1つに固定しない点が、-L・-Rとの違いです。
• X11フォワーディング（ssh -X 接続先 / ssh -Y 接続先）：接続先サーバー上で起動したX Window System（GUI）のアプリケーションの画面を、SSH接続を通じて手元のマシンに表示させる機能です。-Xは信頼できない（untrusted）X11フォワーディング、-Yは信頼できる（trusted）X11フォワーディングを指定します^{-X（untrusted）は、転送先アプリケーションによる一部の操作（他ウィンドウの操作等）を制限するセキュリティ上の追加制約が働きます。-Y（trusted）はこの制約を外すため、より柔軟に動作しますがその分リスクも高くなります。「-Xのほうが単純に上位互換」ではなく、信頼度の違いを表すオプションです。[5]}、という違いがあります。

GnuPG（GPG）による暗号化・署名

gpgコマンドの基本操作

GnuPG（GNU Privacy Guard）は、gpgコマンドを中心に、ファイルやメッセージの暗号化・復号、署名・検証を行うツールです。

• 鍵ペアの生成：gpg --full-generate-key（対話的にアルゴリズム・鍵長・有効期限を選べる、現在推奨されている方法）またはgpg --gen-key（簡易版）。
• 鍵の一覧表示：gpg --list-keys（公開鍵の一覧）、gpg --list-secret-keys（秘密鍵の一覧）。
• 暗号化：gpg -e -r 相手のユーザーID ファイル名（相手の公開鍵を使って暗号化。相手だけが自分の秘密鍵で復号できます）。
• 復号：gpg -d ファイル名.gpg（自分の秘密鍵で復号）。
• 対称暗号化：gpg -c ファイル名（公開鍵を使わず、共有のパスフレーズだけで暗号化する方式。相手にも同じパスフレーズを別途安全な方法で伝える必要があります）。
• 署名：gpg -s ファイル名（署名付きファイルを作成）、gpg -b ファイル名（本文とは別ファイルの署名＝分離署名を作成）。
• 検証：gpg --verify 署名ファイル 対象ファイル（署名が正しいか、改ざんされていないかを確認）。

この記事で扱うSSHのユーザー鍵が主に「ログイン認証」に使われるのに対し、GnuPGの鍵ペアは「暗号化」「署名」という2つの異なる用途の両方に使える、という違いも押さえておくとよいポイントです。

gpg-agentと~/.gnupg/

gpg-agentは、GnuPGの秘密鍵を復号するためのパスフレーズをキャッシュしておくプログラムで、役割の考え方はssh-agentとよく似ています^{実装上は、gpg-agentはssh-agent互換のモードで動作させることもでき、SSHの鍵管理をgpg-agentに一本化する構成も可能です。ただしこれは応用的な構成であり、両者が別々の独立したプログラムであるという基本を理解しておけば試験対策としては十分です。[6]}。GnuPGの鍵（公開鍵・秘密鍵）や、鍵の信頼関係の情報（トラストデータベース）、各種設定ファイルは、ホームディレクトリの~/.gnupg/ディレクトリにまとめて保存されます。

鍵の失効（失効証明書）

GnuPGの鍵ペアの秘密鍵を紛失したり、パスフレーズを忘れてしまったり、鍵が漏えいした疑いがある場合、その公開鍵を「もう有効な鍵として扱わないでほしい」と周囲に知らせる必要があります。これを行うための仕組みが失効証明書です。

現行のGnuPGでは、鍵ペアの生成時に失効証明書が自動生成され、通常は~/.gnupg/openpgp-revocs.d/に保存されます。また、gpg --gen-revoke ユーザーIDで手動生成することもできます。失効証明書は、対象の鍵の秘密鍵がまだ手元にある状態でなければ作成できません。そのため、鍵を紛失してから慌てて作ろうとしても手遅れになる場合があります。鍵ペアを作成した後は、生成された失効証明書を鍵本体とは別の安全な場所に保管しておくことが推奨されています^{失効証明書自体は「まだ発行していない（適用していない）」状態で保管しておき、実際に鍵を失効させたいタイミングで公開鍵サーバーに取り込む（gpg --importしてから公開鍵を再度公開する）、という運用が一般的です。[7]}。

鍵アルゴリズムの比較：RSA・DSA・ECDSA・ED25519

OpenSSH・GnuPGのいずれでも登場する鍵アルゴリズムの特徴を整理します。