Linuxのauthorized_keys管理と公開鍵認証のセキュリティ強化｜鍵の作成・配置・制限・ローテーションの実践ガイド

Linuxサーバーの管理を始めてまず覚えることの一つが、SSHの公開鍵認証への切り替えです。しかし「鍵認証に切り替えた」だけで安心してしまい、authorized_keysファイルの管理が後回しになっているケースは少なくありません。

この記事では、authorized_keysの仕組みと正しいファイル権限の設定から、鍵の強度選定・制限オプションの活用・定期ローテーションまで、現場で実践できる内容を順を追って解説します。鍵認証そのものの安全性を最大限に引き出したい方に向けた実践ガイドです。

SSH公開鍵認証とauthorized_keysとは？

SSH（Secure Shell）の公開鍵認証は、パスワードの代わりに「鍵ペア」を使ってサーバーへのログインを認証する仕組みです。

・秘密鍵（private key）: 手元のPCに保管する鍵。絶対に他者と共有しない
・公開鍵（public key）: サーバー側に登録する鍵。漏洩しても単体では悪用は難しい

公開鍵はサーバーの ~/.ssh/authorized_keys ファイルに1行ずつ登録します。SSHサーバーは接続時に「このPCの秘密鍵は、サーバーに登録された公開鍵と対応しているか」を検証し、対応していればログインを許可します。

パスワード認証と比べた優位点は、サーバー側に認証情報（パスワードそのものやハッシュ）を保存しないため、ブルートフォース攻撃やパスワードリスト攻撃の的になりにくい点です。ただし、authorized_keysの管理が甘いと、この優位性が台無しになります。

公開鍵認証が弱くなる3つの原因

攻撃者が公開鍵認証の隙を突く経路を理解しておくと、対策の優先度が見えてきます。

1. 鍵の強度が不十分

かつて広く使われていた ssh-keygen -t rsa -b 1024 で生成した1024ビットRSA鍵は、現代の計算資源では安全とは言えません。また、DSA鍵（1024ビット固定）は今日では非推奨です。

現在推奨される鍵の種類と鍵長の目安は以下のとおりです。

2. authorized_keysのファイル権限の設定ミス

~/.ssh/authorized_keys のパーミッションが緩い場合、第三者がファイルを書き換えて自分の公開鍵を追加できる状態になります。sshdは StrictModes yes（デフォルト）の設定で権限チェックを行いますが、設定を変更している環境ではこのチェックが無効になっていることもあります。

3. 使われなくなった鍵の放置

退職した社員の公開鍵、廃止されたPCの鍵、過去のテスト用鍵がauthorized_keysに残っていると、その秘密鍵が漏洩した場合にサーバーへの侵入経路となります。鍵の棚卸しをしない運用は、パスワードを永遠に変更しないのと同じリスクを抱えます。

安全な公開鍵認証の設定手順

1. 強力な鍵ペアを生成する

手元のPCで以下のコマンドを実行します。Ed25519形式を選択し、必ずパスフレーズを設定します。

# Ed25519形式で鍵ペアを生成（推奨）
ssh-keygen -t ed25519 -C "your-email@example.com"

# ファイルの保存先を確認（デフォルト: ~/.ssh/id_ed25519）
# パスフレーズを必ず設定すること

# 旧来の環境でEd25519が使えない場合はRSA 4096ビット
ssh-keygen -t rsa -b 4096 -C "your-email@example.com"

パスフレーズは秘密鍵ファイル自体を暗号化します。PCが盗難・紛失に遭っても、パスフレーズなしでは秘密鍵を使えません。

2. 公開鍵をサーバーに配置する

ssh-copy-id コマンドを使うのが最も安全です。このコマンドは公開鍵の追記と権限設定を自動で行います。

# ssh-copy-idで公開鍵を登録（まだパスワード認証が使える状態から）
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server-ip

# 手動で行う場合（ssh-copy-idが使えない環境）
cat ~/.ssh/id_ed25519.pub | ssh user@server-ip \
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && \
  cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

3. ファイル権限を正しく設定する

公開鍵認証が機能するには、~/.ssh ディレクトリと authorized_keys の権限が正しく設定されている必要があります。

# .sshディレクトリは所有者のみアクセス可（700）
chmod 700 ~/.ssh

# authorized_keysは所有者のみ読み書き可（600）
chmod 600 ~/.ssh/authorized_keys

# ホームディレクトリに他ユーザーの書き込み権限がないことを確認
ls -ld ~
# drwxr-xr-x であることを確認（drwxrwxr-x は要修正）
chmod 755 ~

sshd_configで StrictModes yes（デフォルト値）になっていることも確認してください。StrictModesが有効な場合、権限が緩すぎるとsshdは鍵認証を拒否します。sshd_configの全パラメータと推奨値を参照しながら、サーバー設定も合わせて見直すことを推奨します。

authorized_keysの制限オプションで鍵の権限を最小化する

authorized_keysの各エントリには、その鍵の使用範囲を絞り込むオプションを付与できます。最小権限の原則を鍵レベルで実現する重要な機能です。

1. from=（接続元IP制限）

特定のIPアドレスまたはドメインからのみ、その鍵を使ったログインを許可します。

# 192.168.1.100からのみログインを許可するエントリ例
from="192.168.1.100" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... comment

# CIDRブロックで指定する場合
from="192.168.1.0/24" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... comment

# 複数のIPを許可する場合（カンマ区切り）
from="192.168.1.100,10.0.0.50" ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA... comment

サーバー管理専用の鍵は社内IPのみ、自動化処理用の鍵はジャンプサーバーのIPのみに制限すると、鍵が漏洩した場合のリスクを大幅に低減できます。

2. command=（実行コマンド制限）

この鍵でログインした際に、特定のコマンドだけを実行するよう制限します。バックアップ用やrsync用の鍵に設定すると、その鍵が不正使用されてもシェルへのアクセスを防げます。

# バックアップ用：rsyncのみ許可する設定例
command="rsync --server --sender -avz . /backup/",no-pty,no-agent-forwarding ssh-ed25519 AAAAC3... backup-key

# Git用：Gitコマンドのみ許可する設定例
command="/usr/bin/git-shell",no-pty,no-port-forwarding,no-X11-forwarding,no-agent-forwarding ssh-ed25519 AAAAC3... git-key

3. その他の制限オプション

・no-pty: 端末（ターミナル）の割り当てを禁止する。インタラクティブシェルが不要な自動化処理用の鍵に設定する
・no-X11-forwarding: X11転送を禁止する。GUIアプリのリモート実行を制限する
・no-agent-forwarding: SSHエージェント転送を禁止する。多段SSH接続での認証情報の横展開を防ぐ
・no-port-forwarding: ポートフォワーディングを禁止する。トンネルを使った内部ネットワークへのアクセスを防ぐ
・restrict: 上記すべての制限を一括で有効にする省略形（OpenSSH 7.2以降）

制限オプションは組み合わせて使えます。自動化処理用の鍵には少なくとも restrict,command="..." の組み合わせを推奨します。

鍵のローテーションと不審な鍵の監視

1. 定期的な鍵の棚卸し手順

サーバー上のauthorized_keysを定期的に確認し、不要な鍵を削除する習慣が重要です。

# 登録されている公開鍵の一覧（コメント部分でオーナーを確認）
cat ~/.ssh/authorized_keys

# 鍵のフィンガープリントを一覧表示する
ssh-keygen -l -f ~/.ssh/authorized_keys

# sshdが参照するAuthorizedKeysFileの場所を確認する
grep "AuthorizedKeysFile" /etc/ssh/sshd_config

# 不要な鍵を削除する場合（例: 3行目のエントリを削除）
sed -i '3d' ~/.ssh/authorized_keys

鍵のコメント（ssh-keygenの -C オプションに指定した文字列）に「誰の・何のための・いつ作った鍵か」を記録しておくと、棚卸しの際に判断しやすくなります。例として user@hostname-2026-10 のような形式が一般的です。

2. 不審なauthorized_keysエントリの検出

攻撃者がサーバーに侵入した場合、持続的なアクセスを確保するためにauthorized_keysに自分の公開鍵を追加することがあります。これはバックドア設置の典型手口の一つです。定期的な変更監視が有効です。

# authorized_keysの更新タイムスタンプを確認する
stat ~/.ssh/authorized_keys

# 最近24時間以内に変更されたauthorized_keysを検出する（全ユーザー対象）
find /home /root -name "authorized_keys" -newer /proc/uptime -ls 2>/dev/null

# auditdでauthorized_keysへの書き込みを監視するルール
# /etc/audit/rules.d/ssh-key-monitoring.rules に追記
# -w /root/.ssh/authorized_keys -p wa -k ssh_key_change
# -w /home -p wa -k ssh_key_change

# ルール読み込み
# augenrules --load

auditdによる authorized_keys の変更監視は、侵害後の証跡確保にも役立ちます。不審プロセス・ネットワーク接続の調査方法と組み合わせることで、侵入の痕跡をより早期に掴めます。

中小企業でも今日からできること

セキュリティ担当者1人でも取り組めるステップを優先度順に整理します。

・今すぐ: 既存のauthorized_keysを棚卸しし、不明な鍵・不要な鍵を削除する
・今すぐ: 新しい鍵をEd25519形式で作り直し、パスフレーズを設定する
・今週: ~/.ssh のパーミッションを確認・修正する（700 / 600）
・今週: sshd_configでStrictModes yes、PasswordAuthentication noを確認する
・今月: 自動化処理用の鍵にcommand=とrestrictオプションを付与する
・定期的に: 四半期に1度、全サーバーのauthorized_keysを棚卸しする

ブルートフォース対策にはfail2banによる自動ブロック設定との組み合わせが効果的です。公開鍵認証でパスワード認証を無効化したうえで、fail2banを導入することで多層的な防御が実現できます。

よくある誤解と注意点

・「公開鍵認証に切り替えた＝パスワード認証を無効にした」は同義ではない: sshd_configに PasswordAuthentication yes が残ったままでは、鍵認証と並行してパスワード認証も有効です。必ず PasswordAuthentication no に設定してsshdを再起動する
・「公開鍵を渡しても大丈夫」は正しいが過信は禁物: 公開鍵の漏洩は問題ないですが、対応する秘密鍵の漏洩は深刻です。秘密鍵のバックアップ先・コピー先も管理対象に含めること
・「ssh-copy-idを使えば設定は完璧」は誤解: ssh-copy-idは公開鍵の配置を簡単にするツールです。制限オプションの設定や定期ローテーションは別途行う必要がある
・rootアカウントのauthorized_keys管理: /root/.ssh/authorized_keysに直接ログイン用の鍵を登録している環境では特に厳格な管理が必要。一般的にはrootへの直接SSH接続を禁止し（PermitRootLogin no）、一般ユーザー経由でsudoするアーキテクチャを推奨する
・一括代入型の鍵管理の罠: 複数のサーバーに同じ公開鍵を登録していると、秘密鍵の漏洩が全サーバーに波及する。サーバーグループごとに鍵を分けることがよりよい姿といえる

本記事のまとめ

公開鍵認証は「設定したら終わり」ではなく、鍵の生成・配置・制限・ローテーション・監視という継続的な管理サイクルを回してこそ効果を発揮します。まずは既存のauthorized_keysの棚卸しから始めてみてください。