6.2OpenSSHサーバーの設定と管理

リモート管理の生命線がsshd（OpenSSH サーバーデーモン）です。デフォルト設定のまま外部公開すると総当たり攻撃の的になるため、L2 ではroot ログインの禁止・鍵認証への一本化・接続ユーザーの絞り込みという定番の堅牢化を、設定ディレクティブのスペルまで正確に扱えることが問われます。

6.2.1sshd_configの主要ディレクティブ

• 設定ファイルは/etc/ssh/sshd_config。編集後は構文チェック（sshd -t）してからsystemctl reload sshdで反映するのが安全（誤った設定での再起動はロックアウトの危険）。
• PermitRootLogin＝root での直接ログイン可否。noで禁止、prohibit-passwordでパスワード認証のみ禁止（鍵認証でのroot接続は許可）。堅牢化の定番はno。
• PubkeyAuthentication＝公開鍵認証の有効/無効（既定yesが多い）。PasswordAuthentication＝パスワード認証の可否。鍵認証を徹底するならPasswordAuthentication noに設定する。
• AllowUsers＝接続を許可するユーザーをスペース区切りで列挙（例AllowUsers alice bob）。指定されなかったユーザーは全て拒否されるホワイトリスト方式。

6.2.2ホスト鍵と鍵認証の仕組み

• ホスト鍵＝サーバー自身の身元証明鍵。/etc/ssh/ssh_host_*_key（秘密鍵）とssh_host_*_key.pub（公開鍵）のペアがアルゴリズム（rsa/ecdsa/ed25519等）ごとに存在し、通常はパッケージインストール時に自動生成される。
• クライアント側は初回接続時にホスト鍵のフィンガープリントを記録（~/.ssh/known_hosts）し、次回以降は鍵が変わっていないかを検証する（中間者攻撃の検知）。
• 公開鍵認証の流れ＝クライアントの秘密鍵で署名→サーバーが対応する公開鍵（~/.ssh/authorized_keysに登録）で検証。サーバー側にはクライアントの公開鍵のみを置く（秘密鍵は絶対に配布しない）。

典型的な堅牢化シナリオで確認しましょう。「インターネットに公開する踏み台サーバーで、root の直接ログインを禁止し、一般ユーザー alice と bob だけに接続を絞り、パスワード認証を無効化して鍵認証のみにしたい」場合、/etc/ssh/sshd_configには次を設定します：PermitRootLogin no（root は直接ログイン不可、必要ならsudoで昇格）、AllowUsers alice bob（この2名以外は接続不可）、PasswordAuthentication no（パスワードでの認証を拒否）、PubkeyAuthentication yes（鍵認証を許可、通常は既定で有効）。ここで注意したいのは適用順序と検証です。設定変更後にいきなりsystemctl restart sshdすると、鍵の設定ミスがあった場合に誰も接続できなくなるリスクがあるため、可能ならコンソールアクセスを確保した状態でsshd -tによる構文チェック→別セッションを開いたまま反映→新規接続で疎通確認、という手順を踏みます。またPermitRootLogin prohibit-passwordという中間的な設定もあり、これは「パスワードでのroot直接ログインは拒否するが、鍵認証でのroot接続は許可する」もので、緊急時のroot作業を鍵認証に限定したい場合に使われます。ホスト鍵が変わった（サーバー再構築等）場合、クライアントはknown_hostsの記録と食い違うため警告を出しますが、これは正当な再構築でも中間者攻撃でも同じ警告になるため、変更の正当性を運用者が確認してからknown_hostsを更新する運用が重要です。

6.2.3この節のまとめ

• 設定は/etc/ssh/sshd_config。PermitRootLogin no／PasswordAuthentication no＋PubkeyAuthentication yes／AllowUsersで堅牢化
• ホスト鍵（ssh_host_*_key秘密／.pub公開）がサーバー身元証明。反映前にsshd -tで構文チェック