SSH要塞化の終着点：ブルートフォースの無力化とプロトコル層から見た「パスワード認証」という原罪
世界中のダークウェブやランサムウェアのC2インフラを観測していると、インターネットに露出したLinuxサーバーに対する最初の攻撃ベクトルが、いまだにSSH（Port 22）への総当たり攻撃（ブルートフォースアタック）や辞書攻撃であることに気付く。ゾンビボットネットが吐き出す毎秒数千回のTCP SYNと認証要求は、セキュリティ運用の現場において最もありふれた、そして最も無視できない背景雑音だ。
「パスワード認証を有効にし、rootでの直接ログインを許可する」という行為は、要塞の門の鍵を壊れやすい木製にし、しかも合鍵をマットの下に隠しておくようなものだ。
本稿では、sshd_configにおける PermitRootLogin no と PasswordAuthentication no の設定という、いわばハーデニングの「イロハのイ」を、単なるチェックリストの消化作業としてではなく、プロトコル仕様の欠陥、暗号学的優位性、そして攻撃者のキルチェーンを断ち切るアーキテクチャの観点から徹底的に解剖する。
—
1. なぜ「パスワード認証」はアーキテクチャ上の欠陥なのか
現代の認証モデルにおいて、パスワードという概念は人間工学的にも暗号学的にも破綻している。人間が覚えられるエントロピーの限界と、GPUやASICを用いたハッシュクラッキング（hashcatなど）の処理能力の非対称性は、もはや防衛側の勝負を不可能にしている。
SSHプロトコル（RFC 4252）において、パスワード認証はサーバーに対して平文（TLS/SSLやSSHのトランスポート層で暗号化はされているが、認証プロトコル自体としては）に近い秘密を直接送信し、サーバー側でそれを検証する。これは、万が一サーバー側のメモリダンプが取得されたり、あるいは巧妙なサイドチャネル攻撃や実装バグ（例：OpenSSLのHeartbleedや過去のOpenSSHの脆弱性）に直面した際、認証の秘密そのものが漏洩するリスクを常に孕む。
さらに、パスワード認証が存在する限り、攻撃者は以下の攻撃ベクトルを常時維持できる。
1. 無限の試行回数: レートリミットが甘い環境であれば、無限にクレデンシャルスタッフィングやブルートフォースを試行できる。
2. ソーシャルエンジニアリング: フィッシングやキーロガーによって、ユーザーの脆弱なパスワードが容易に奪取される。
これを根絶する唯一の解が、公開鍵暗号方式によるチャレンジ・レスポンス認証への完全な移行である。
—
2. 公開鍵認証の数学的優位性と sshd_config の要塞化
公開鍵認証では、サーバー側には公開鍵（authorized_keys）のみを置き、秘密鍵はクライアント側のセキュアなストレージ（TPMやハードウェアセキュリティキーなど）から一歩も外に出さない。認証プロセスでは、サーバーが生成したランダムなチャレンジ（nonce）に対して、クライアントが秘密鍵でデジタル署名を生成し、サーバーがそれを公開鍵で検証する。
これにより、ネットワーク上に認証の秘密が流出することは原理的にあり得なくなる。
この要塞化を確実に実装するための設定が、/etc/ssh/sshd_config における以下のディレクティブだ。現代のOpenSSH（v8.2以降を強く推奨）において、最低限適用すべきプロダクションレベルの設定を以下に示す。
# ==========================================
# OpenSSH Server Hardening Configuration
# Target: Production Linux Environments
# ==========================================
# 1. ルートユーザーによる直接SSHログインを完全に禁止
# 監査証跡（auditdなど）の追跡性を担保するため、管理者であっても
# まず一般ユーザーでログインし、sudoやsuで昇格することを強制する。
PermitRootLogin no
# 2. パスワード認証の完全無効化
# ブルートフォースアタックの余地をプロトコルレベルで排除する。
PasswordAuthentication no
# 3. 空パスワードの許可を禁止（デフォルトだが明示的に指定）
PermitEmptyPasswords no
# 4. チャレンジ・レスポンス認証（KBD-interactive）の無効化
# パスワード認証が無効であっても、PAM経由のkeyboard-interactiveが有効なままだと
# パスワード入力を促すバックドアになり得るため確実に無効化する。
KbdInteractiveAuthentication no
# 5. 許可する認証方式を公開鍵のみに制限
PubkeyAuthentication yes
AuthenticationMethods publickey
# 6. エージェント転送やポートフォワーディングの厳格化（必要に応じて）
AllowTcpForwarding no
X11Forwarding no
AllowAgentForwarding no設定適用後の重要プロセス
設定ファイルを書き換えただけでは、デーモンには反映されない。必ず構文チェックを行ってからサービスを再起動すること。ここでミスをするとリモートから二度とログインできなくなる（セルフDDoS）ため、現在のセッションを切断せずに、別ウィンドウで必ずテスト接続を行うのがインフラエンジニアの鉄則だ。
# 1. 設定ファイルの構文エラーチェック
sudo sshd -t
# 2. 問題がなければサービスを再起動（Systemd環境）
sudo systemctl restart sshd—
3. ホワイトハッカーの視点：設定の「その先」にある盲点
PermitRootLogin no と PasswordAuthentication no を入れたからといって、夜枕を高くして眠れるわけではない。高度な脅威アクターや内部不正者は、別のレイヤから侵入を試みる。ここでは、現場のセキュリティアーキテクトが考慮すべき「防衛の次の一手」を提示する。
A. 鍵の管理不備（Stale Keys）とエージェントハイジャック
公開鍵認証の弱点は「鍵そのものが盗まれた場合」にある。特に、開発者のローカル端末がマルウェアに感染し、~/.ssh/id_rsa が抜かれたり、ssh-agent がハイジャックされたりするケースが後を絶たない。
- 対策: 鍵の強度は最低でも
ED25519（楕円曲線暗号）を使用するか、YubiKeyなどのハードウェアセキュリティキーを用いたFIDO2/U2F（sk-ssh-ed25519）を強制すること。RSAはもはやレガシーであり、サイドチャネル攻撃や鍵長増加のコスト面から避けるべきである。
# 推奨される強固なED25519鍵の生成（パスフレーズの設定は必須）
ssh-keygen -t ed25519 -a 100 -C "sec-ops-202X@company.internal"B. プロトコルバージョンのフォールバックとレガシー暗号の排除
古いクライアントからの接続を受け入れるために、古い暗号スイート（Cipher）やMACアルゴリズムを残しているシステムが多い。これらは将来的な暗号解読リスク（量子コンピュータの台頭を含む）やダウングレード攻撃の温床となる。
sshd_config には、モダンかつ安全なアルゴリズムのみを明示的に指定する。
# 強固な暗号スイートとMACの強制（sshd_configに追加）
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.comC. 多層防御（Defense in Depth）としてのネットワーク・アクセス制御
SSHのポート（22番）をグローバルIPに対して無防備に開放している時点で、アーキテクチャの敗北と言える。
- ゼロトラスト・ネットワーク・アクセス（ZTNA）やAWS Systems Manager (SSM) Session Manager、あるいはCloudflare Tunnelなどの仕組みを導入し、そもそもSSHポートをインターネットに直接露出させない設計が現代のゴールドスタンダードである。
- やむを得ず公開する場合は、
Fail2banなどの動的ファイアウォール連携に加え、ポートノッキングやVPN経由でのみアクセスを許可するセグメンテーションを徹底すべきだ。
—
結び：セキュリティは「状態」ではなく「プロセス」である
sshd_config の数行を書き換えることは、要塞化のスタートラインに立ったに過ぎない。サイバーセキュリティの領域において、静的な設定完了イコール安全を意味することは絶対にない。
攻撃者は常に新しいプロトコルの実装ミスや、人間の運用における隙を突いてくる。だからこそ、我々エンジニアは仕様の背景にある数学的・プロトコル的な挙動を深く理解し、システムを常に監査・アップデートし続けなければならない。門を固く閉ざし、真に信頼できる鍵を持つ者だけを通す――その徹底こそが、インフラを守り抜く唯一の道である。
コメント