SSH鍵認証入門：公開鍵・秘密鍵とssh configの仕組みを理解する

前章ではSSHを使った初回ログインを行いました。パスワード認証は直感的ですが、脆弱なパスワード、使い回し、総当たり攻撃のリスクが伴います。本番運用の標準的なアプローチはSSH公開鍵認証です。

「公開鍵、秘密鍵、ホスト鍵」という用語は初心者を混乱させがちです。まず基本原則を覚えましょう：ユーザー鍵は「あなたが誰であるか」を証明し、ホスト鍵は「サーバーが正規のものであるか」を証明します。

一、公開鍵と秘密鍵の連携

物理的な錠前と鍵に例えると以下のようになります：

サーバーは公開鍵のみを保持し、秘密鍵を受け取る必要はありません。認証時は暗号学的なチャレンジレスポンス方式によって検証が行われ、秘密鍵そのものがネットワーク上を流れることはありません。

したがって、「秘密鍵をサーバーにアップロードする」という指示を見かけた場合は危険です。秘密鍵を公開Gitリポジトリ、ブログの画像、チャット、クラウドストレージで共有してはいけません。

二、学習用VPS専用の鍵ペアを生成する

MacまたはLinuxのローカル端末で、独立したEd25519鍵ペアを生成します：

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_vps_learning -C "vps-learning"

各オプションの意味：

• -t ed25519：現代的で安全性の高いEd25519署名アルゴリズムを選択；
• -f：既存の鍵を誤って上書きしないよう出力ファイル名を明示；
• -C：識別用のコメントを付与（認証には影響しません）。

プロンプトが表示されたらパスフレーズを設定します。日常業務で使用する秘密鍵にはパスフレーズを設定することが推奨されます。OSのキーチェーンやssh-agentを活用すれば、接続ごとの入力負担を軽減できます。

生成される2つのファイル：

~/.ssh/id_ed25519_vps_learning       秘密鍵（絶対に外部流出させてはならない）
~/.ssh/id_ed25519_vps_learning.pub   公開鍵（サーバー側に登録する）

三、公開鍵をサーバーに登録する

最も確実な方法は、VPS事業者の管理パネルにあるSSH Key登録機能を利用し、サーバー作成時またはOS再インストール時に.pubファイルの内容を登録することです。既存環境に対してはssh-copy-idコマンド等で転送することも可能です。

いずれの手法であっても、サーバー側では対象ユーザーの以下ファイルに公開鍵が追記されます：

~/.ssh/authorized_keys

SSHはファイル権限に厳格です。一般的に~/.sshディレクトリは所有者のみアクセス可能（700）、authorized_keysは所有者のみ書き込み可能（600）である必要があります。権限が過剰に緩い場合、セキュリティ保護のため認証が拒否されます。

確認すべき重要事項：

1. 正しいLinuxユーザーのディレクトリに配置されているか； 2. 貼り付けたのは.pubの内容であり、秘密鍵ではないか； 3. パスワード認証を遮断する前に、別ウィンドウで鍵認証の成功を確認したか。

四、SSH configで接続コマンドを簡略化する

毎回ssh -i ~/.ssh/id_ed25519_vps_learning admin@203.0.113.10と入力するのは煩雑です。

ローカル端末の~/.ssh/configに設定を追記します：

Host learning-vps
  HostName 203.0.113.10
  User admin
  Port 22
  IdentityFile ~/.ssh/id_ed25519_vps_learning
  IdentitiesOnly yes

以降は以下のコマンドだけで接続できます：

ssh learning-vps

Hostは任意のローカル別名、HostNameが実際のIPアドレスです。IdentitiesOnly yesを指定することで、多数の鍵を保持している場合に意図しない鍵の試行によるエラーを防ぎます。

五、ユーザー鍵とホスト鍵を混同しない

初回接続時に表示されるSHA256ハッシュはホスト鍵の指紋です。ホスト鍵が将来突然変化した場合、OS再インストールによるものか、アドレスの再利用や不正な通信割り込みがないかを確認してください。

六、安全な移行フロー

パスワード認証から鍵認証へ切り替える際は、次の手順を踏みます：

1. Webコンソール等での救済手段を確認する； 2. 日常管理用ユーザーを作成し、公開鍵を登録する； 3. 現在の接続セッションを維持したまま、別ターミナルから鍵ログインをテストする； 4. 新ユーザーに必要なsudo権限が付与されているか確認する； 5. sshd_configでroot直接ログインやパスワード認証の無効化を段階的に設定する； 6. 変更の都度、新規セッションを開いて検証し、認証ログを確認する。

ポート、ファイアウォール、ユーザー、認証設定を同時に変更しないことが鉄則です。既存の接続セッションを1つ維持しておくことが、最大のセーフティネットになります。

七、鍵のライフサイクル管理

• デバイスや用途ごとに識別可能な個別の鍵ペアを使用する；
• 端末の廃棄やメンバー離脱時は、authorized_keysから該当の公開鍵を削除する；
• 秘密鍵の漏洩が疑われる場合は、直ちに新しい鍵ペアを生成・登録し、旧公開鍵を無効化する；
• 秘密鍵のバックアップは安全に暗号化し、復元テストを行っておく；
• 「鍵に有効期限がない」ことを「永遠に更新しなくてよい」と誤認しない。

八、まとめ

SSH鍵認証は単なる長いパスワードではありません。「公開可能な錠前（公開鍵）」と「手元に秘匿する鍵（秘密鍵）」を数学的に分離する仕組みです。~/.ssh/configを活用することで、安全かつ効率的な接続管理が実現します。

安全な移行の前提条件は2つだけです。「秘密鍵を絶対に外部に出さないこと」、そして「既存の接続を維持したまま別セッションで検証すること」です。

よくある質問

.pubファイルを他人に送信しても安全ですか？

公開鍵はその性質上、配布されることを前提としていますが、アクセス権を与えるべき信頼できるシステムにのみ登録してください。秘密鍵は絶対に送信してはいけません。

パスフレーズ付き秘密鍵で自動バッチ処理を行うにはどうすればよいですか？

権限を絞った専用の鍵、ssh-agent、一時トークン、シークレット管理システムの利用を検討してください。利便性のためにパスフレーズなしの特権鍵を無差別に配置することは避けてください。

パスワード認証は完全に削除すべきですか？

鍵認証、sudo権限、Webコンソールの動作確認が完了していれば無効化が推奨されます。ただし、動作未検証のまま機械的に閉じることは避けてください。

参考リンク

• OpenBSD Manual Pages：ssh-keygen
• OpenBSD Manual Pages：ssh_config
• OpenBSD Manual Pages：sshd_config
• Ubuntu Server：OpenSSH server
• RFC Editor：RFC 5737 IPv4アドレスのドキュメント用予約