境界線を再定義する：SSHパスワード認証の「完全廃絶」とEd25519による暗号学的要塞化
現代のインフラストラクチャにおいて、SSH（Secure Shell）は単なるリモートログインツールではない。それは、コントロールプレーンへと繋がる最深部への「聖域の門」だ。しかし、多くの現場では依然として「利便性」という名の脆弱な妥協が、攻撃者にレッドカーペットを敷き続けている。
我々ホワイトハッカーの視点から言えば、パスワード認証を残しておくことは、最新の防弾ガラスを導入しながら、鍵穴に針金を突っ込む余地を残しているのと同義である。本稿では、単なる設定変更の推奨を超え、なぜパスワード認証がプロトコルレベルで危険なのか、そしてなぜEd25519への移行が不可避なのかを、低レイヤの力学と耐量子暗号（PQC）への過渡期という視点から詳解する。
—
1. パスワード認証という「攻撃表面」の解剖
多くのエンジニアは、パスワード認証の脆弱性を「ブルートフォース（総当たり攻撃）」や「辞書攻撃」に限定して考えがちだ。しかし、真の脅威はそれだけではない。
メモリ空間におけるリスクとPAMのオーバーヘッド
SSHの認証プロセスは、OSの PAM (Pluggable Authentication Modules) と深く連動する。パスワード認証が有効な場合、sshdプロセスはユーザーが入力した資格情報をメモリ空間に保持し、ハッシュ計算やバックエンドの認証データベース（LDAPやActive Directory等）との照合を行う。
この一連のプロセスにおいて、仮に sshd 自体やリンクされているライブラリに Heap Overflow や Use-After-Free 系の脆弱性（過去の CVE-2001-0144 や、より新しい実装上の不備）が存在した場合、認証前の段階でリモートコード実行（RCE）を許す足がかりを与えるリスクが残る。パスワード認証をプロトコルレベルで「無効」にすることは、これらの複雑なロジックパスをまるごとバイパスさせないという「攻撃表面の最小化」を意味する。
タイミング攻撃の回避
パスワード認証には、有効なユーザー名と無効なユーザー名で応答時間が微妙に異なる「タイミング攻撃」の隙が生まれやすい。OpenSSH開発チームはこの対策を講じているが、ネットワーク遅延の統計的解析により、依然としてユーザーの存在確認（User Enumeration）が可能になるケースがある。公開鍵認証を強制し、パスワード認証を拒絶することで、この種のサイドチャネル攻撃の成功率は劇的に低下する。
—
2. Ed25519：なぜRSAやECDSAでは不十分なのか
現在、多くの環境で RSA 2048/4096 が利用されているが、我々プロフェッショナルの推奨は一貫して Ed25519 である。
決定論的署名の安全性
Ed25519（Edwards-curve Digital Signature Algorithm）が優れているのは、そのパフォーマンスだけではない。特筆すべきは「決定論的署名」である点だ。
ECDSA などの古い規格では、署名の生成に高品質な乱数生成器（RNG）を必要とする。もしカーネルの乱数生成に偏りがあったり、仮想環境の初期化直後でエントロピーが不足していたりすると、署名から秘密鍵が逆算される致命的な脆弱性（PlayStation 3のハックで有名になった手法）を招く。Ed25519 は設計上このリスクを排除しており、実装の不備に左右されない堅牢性を持っている。
耐量子暗号（PQC）への布石
現在のRSAや楕円曲線暗号は、将来的な量子コンピュータ（Shorのアルゴリズム）によって解読される運命にある。OpenSSH 8.9以降では、耐量子ハイブリッド鍵交換アルゴリズム（sntrup761x25519-sha512@openssh.com）がデフォルトで導入され始めている。このハイブリッド構成においても、ベースとなる楕円曲線として Ed25519 はその信頼性から中心的な役割を担っている。
—
3. 実践：sshd_config の要塞化（Hardening）
単に PasswordAuthentication no を書くだけでは不十分だ。設定ファイル /etc/ssh/sshd_config において、攻撃者が試行錯誤する余地を徹底的に潰す設定例を以下に示す。
# ------------------------------------------------------------
# SSH Server Hardening Configuration
# ------------------------------------------------------------
# 1. パスワード認証の完全無効化
# 全てのパスワードベースの認証を拒否する
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
# PAMは有効にするが、認証自体はPubkeyで行う。
# 完全にnoにすると、セッション管理やリミット設定が効かなくなるため注意。
# 2. 公開鍵認証の強制とアルゴリズムの限定
PubkeyAuthentication yes
# 許可する公開鍵の暗号化アルゴリズムを制限（RSAを排除しEd25519を最優先）
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
PubkeyAcceptedAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-ed25519
# 3. ルートログインの禁止
# 攻撃者が最初に狙う「root」というユーザー名でのアクセスをプロトコルレベルで遮断
PermitRootLogin no
# 4. 認証試行回数とタイムアウトの厳格化
# 3回失敗したら切断。ブルートフォースの効率を極限まで下げる。
MaxAuthTries 3
# 認証までの待機時間を短縮（デフォルト120秒は長すぎる）
LoginGraceTime 30
# 5. プロトコルレベルでの暗号セット固定
# 脆弱な暗号（CBCモードやSHA-1等）を完全に排除
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,sntrup761x25519-sha512@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com設定反映前には、必ず sshd -t で構文チェックを行うことを忘れてはならない。
# 設定ファイルの構文チェック（エラーが出なければOK）
sudo sshd -t
# 設定の反映
sudo systemctl restart ssh—
4. 生成AI時代の防御層：プロンプトインジェクションとSSH
現代のシステム管理において、AIエージェントがインフラ操作を代行するケースが増えている。ここで新たな脆弱性として浮上するのが、AIへの指示（プロンプト）を介した「間接的な認証情報の奪取」である。
例えば、AIに「サーバーのセットアップを自動化して」と指示した際、攻撃者が仕込んだ悪意あるリポジトリから sshd_config を上書きさせるようなコードが含まれていた場合、AIが良かれと思って PasswordAuthentication yes に書き戻してしまうリスクがある。
これを防ぐには、「不変（Immutable）な構成管理」と「ガードレイル（Guardrails）」の設計が不可欠だ。
- 監査としてのポリシーチェック: CI/CDパイプラインにおいて、
ssh -Gコマンドを使用し、最終的に適用される設定が組織のセキュリティポリシー（パスワード認証禁止）に合致しているかを自動テストする。 - 実行環境の分離: AIエージェントがSSH鍵にアクセスできる範囲を、特定の踏み台（Bastion）サーバーのみに限定し、そこからの通信ログをリアルタイムで異常検知（SIEM）に流し込む。
—
5. 監査の観点：見落としがちな「裏口」
設定を終えた後、チーフセキュリティスペシャリストとして確認すべきは以下の項目だ。
1. AuthorizedKeysFile のパーミッション:
~/.ssh/authorized_keys が所有者以外に書き込み権限がある場合、SSHは安全のために鍵を無視するが、設定ミスによっては意図しない書き換えを許す。
2. Match ブロックの罠:
設定ファイルの末尾に Match ブロックがある場合、それ以前の設定が上書きされている可能性がある。特定のIPレンジだけパスワードを許可するような設定が残っていないか徹底的に洗う必要がある。
3. エージェントフォワーディングの危険性:
AllowAgentForwarding が yes になっている場合、侵害されたリモートサーバー上の攻撃者が、クライアント側のSSHエージェントを悪用して他のサーバーへ横展開（Lateral Movement）するリスクがある。必要最小限に限定すべきだ。
結論
SSHのパスワード認証を無効化し、Ed25519による公開鍵認証を強制することは、単なる「推奨設定」ではなく、現代のサイバー戦域における「最低限の礼儀」である。攻撃者は常に、我々が「面倒だ」と感じて放置したわずかな隙間を突いてくる。
技術的な裏付けを持って、レガシーな認証方式を切り捨てる勇気を持つこと。それが、最高峰の防衛ラインを構築するアーキテクトに求められる資質である。
コメント