SSHサーバーの設定を強化する方法
最終更新:
sshd_configは、SSHサーバーのセキュリティ姿勢そのものを1つのテキストファイルにまとめたものです。しかも多くのシステムでは、セキュリティのためではなく互換性のために最適化された状態で出荷されます。パスワードログインは既定で有効、rootは鍵さえ使えばログインでき、アイドルセッションは無期限に続き、サーバーが提供するアルゴリズムは数年前にインストールされたOpenSSHのバージョンが決めたものです。強化とは2021年のチェックリストを写すことではありません。アルゴリズムは廃止され、デフォルトは変わり、5年前に模範的だった設定が今日では弱いこともあります。この記事では、各変更が実際に何をするのか、決定の順序がなぜ重要なのか、そして自分を締め出さずに新しい設定をテストする方法を説明します。自分のファイルはSSHサーバー設定監査ツールで1行ずつ監査できます。2026-11-13付けのベースラインと照合し、すべてブラウザ内で行います。
デフォルトは出発点であり、強化策ではない
OpenSSHは、新規インストールが可能な限り多くの人にとって動作するよう選ばれたデフォルトで出荷されます。それこそが、それらがセキュリティ姿勢ではない理由です。sshd_configのマニュアルページに記された現在のデフォルトには、PasswordAuthentication yes、PermitRootLogin prohibit-password、MaxAuthTries 6、LoginGraceTime 120秒、ClientAliveInterval 0が含まれます。最後の0は、アイドルセッションが決して終了しないことを意味します。どれもバグではありません。どれも意図的な互換性の選択であり、強化監査ではどれも指摘事項になります。
実際的な帰結として、誰も強化したことのないサーバーは今もパスワード推測で到達でき、盗まれた鍵によるrootログインを今も受け入れ、放置されたセッションを無期限に開いたままにします。デフォルトは時間とともに変わります。OpenSSH 10.6のものはOpenSSH 7のものとは異なります。つまり「何も変えていない」というのは中立な発言ではありません。セキュリティ姿勢が、たまたまインストールしたバージョンの決めたものになっているという意味であり、それを知る唯一の方法はファイルを読むことです。これが監査の最初の仕事です。見えないデフォルトを見える化すること。ファイルに現れないディレクティブも有効だからです。
パスワードを無効化することは、ポート変更より常に勝る
sshd_configで最も効果的な変更は、PasswordAuthentication noとPubkeyAuthentication yesの組み合わせです。この瞬間から、推測されたものでも、漏洩したものでも、フィッシングで奪われたものでも、パスワードは一切セッションを開けなくなります。デーモンがその種の証明を受け付けなくなるからです。鍵認証は、攻撃を「人間が選んだ秘密を推測する」ことから「ネットワークを決して通らない秘密鍵ファイルを盗む」ことへと変えます。だからこそMozillaを含むあらゆる強化ベースラインがここから始まります。この記事から1つだけ持ち帰るとすれば、これです。鍵ペアを生成し（SSH鍵スイートと関連記事SSH鍵の解説を参照）、公開鍵を設置し、それでログインできることを確認してから、パスワードを無効化してください。
一方、ポートを22から目立たないものに変えることは強化ではありません。隠蔽です。ログのノイズは減ります。インターネット全体のスキャナーの多くは22番ポートしか叩かないからです。しかし、スキャンする手間を惜しまない攻撃者を止めることはできません。ポートスキャンは数秒でデーモンを見つけ、その背後の強さは設定そのものの強さです。だから監査ツールは22以外のポートを情報としてのみ扱い、採点される改善とは決して見なしません。切り替える前に知っておくべき落とし穴が1つあります。PAMを使うシステムでは、PasswordAuthentication noだけでは不十分です。キーボードインタラクティブ認証がPAMにパスワードを受け入れさせる可能性があるため、/etc/pam.d/sshdのPAMスタックもパスワードを拒否しなければなりません。Mozillaのガイドラインはこれを明記しており、最も見落とされやすい変更の後半分です。
rootログイン：prohibit-passwordが実際に許可するもの
PermitRootLoginには4つの値があり、その違いは監査証跡があるかないかの違いです。デフォルトのprohibit-passwordは、rootのログインを許可します。ただしパスワードではログインできません。盗まれたroot鍵はそれでも素通りし、セッションがrootになった時点で、ログにはどの管理者かを区別するものが何も残りません。MozillaのModernプロファイルはこれをNoに設定します。これが強化された答えです。rootは決してログインアカウントであるべきではありません。名前付きユーザーでログインし、sudoを使う。そうすれば、すべての特権操作が個人に紐づきます。
中間の値が存在するのには理由があり、恐れるより知るべきです。forced-commands-onlyは、提示された鍵がauthorized_keysで単一のコマンドに制限されている場合にのみrootログインを許可します。バックアップや監視スクリプトが使うパターンであり、自動化のための正当で意図的な選択です。正当でないのはyesで、rootのパスワードログインを許可し、あらゆる監査でエラーになります。実用的なルールはこうです。人間がrootでログインするなら、設定が間違っています。スクリプトなら、鍵を1つのコマンドに制限し、コメントにそう書いてください。そうしなければ、次にファイルを読む人がそれを「修正」してしまいます。
アルゴリズムの廃止は動く標的
設定内のアルゴリズムには有効期限があり、思っているより短いものです。OpenSSH 10.0（2025-04-09リリース）はDSA（ssh-dss）のサポートを完全に削除し、有限体Diffie-Hellmanをサーバーのデフォルト鍵交換から外し、ポスト量子ハイブリッドのmlkem768x25519-sha256をデフォルトの鍵合意としました。2021年のブログ記事からコピーした設定には、diffie-hellman-group1-sha1、3des-cbc、arcfour、hmac-md5が今も並んでいるかもしれません。現代の監査ではすべてエラーであり、その一部はインストール済みのデーモンがもはやサポートすらしていません。設定は変わっていません。世界が変わったのです。
だからこそ強化ベースラインには日付が必要であり、再確認は後付けではなく仕事の一部なのです。MozillaのModernプロファイル（curve25519鍵交換、chacha20-poly1305とAES-GCM暗号、SHA-2の暗号化後認証（EtM）MAC）は参照標準ですが、OpenSSH 10.0がデフォルトとしたポスト量子鍵交換より前に書かれたものです。だから2026年の監査では、それらに加えてmlkem768x25519-sha256とsntrup761x25519-sha512も受け入れます。最新を保つ習慣は安上がりです。年に1〜2回、サーバーでssh -Q kex、ssh -Q cipher、ssh -Q macを実行し、インストール済みバージョンが実際に何を提供するかを確認し、最新のMozillaガイドラインと照らし、同じファイルを監査ツールで再実行してください。2021年のクリーンなスコアは歴史文書であり、現状文書ではありません。
MatchブロックとInclude：クリーンな監査が嘘をつく2つの方法
設定ファイルは設定の平坦なリストではありません。条件分岐を持つプログラムであり、2つの機能によって、強化されているように読めるファイルが、そうでないかのように振る舞うことがあります。1つ目はMatchブロックです。Match User、Match Group、Match Addressブロック内のディレクティブは、条件が満たされた場合にのみ適用されます。マニュアルページは明記しています。キーワードが複数の満たされたMatchブロックに現れる場合、最初のインスタンスのみが適用されると。グローバルなPasswordAuthentication noの後に、あるグループだけこっそりパスワードを再有効化するMatchブロックが続くのは現実の設定であり、まさに1行ずつ読むだけでは見落とす類のものです。Matchブロック内の指摘は条件的であり、決してグローバルではありません。誠実な監査はそのように範囲を限定します。
2つ目はIncludeです。最近のディストリビューションはsshd_configを複数ファイルに分割します（通常は/etc/ssh/sshd_config.d/*.conf）。Includeディレクティブは、それが現れる位置で、辞書順にそれらのファイルを取り込みます。最初に得られた値が勝つため、取り込まれたファイルで設定されたディレクティブは、メインファイルの後ろにある同じディレクティブを覆い隠します。読んでいる行が、実際に効いている行ではないのです。ブラウザで動く監査ツールはIncludeをたどることができません。ファイルがあなたのマシンにないからです。だから「未追跡」としてフラグを立て、パスを列挙します。監査するときは1つのファイルではなくディレクトリ全体を監査し、重複したディレクティブは無視できるタイプミスではないことを覚えておいてください。最初のものが勝ち、2つ目は次の編集者を混乱させるだけの死んだテキストです。
安全な展開：扉を閉める前にテストする
sshd_configの変更にはどれも同じリスクがあります。タイプミスがデーモンの再起動を拒み、正しい構文でも誤った設定があなた自身を拒むことがあります。両方を避ける展開手順は短く、交渉の余地がありません。まず、実行中のサービスに触れる前にsshd -tで構文をチェックします。ファイルを解析し、何も起動せずにエラーを報告します。次にデーモンを再起動または再読み込みし、その後でテストします。設定を編集しながら唯一のセッションを閉じることは決してしないでください。
テスト自体が規律です。既存のセッションを開いたままにし、2つ目のセッションを開き、新しいルールのもとで新規ログインします。2回目のログインが成功すれば変更は安全で、最初のセッションを閉じて構いません。失敗すれば、開いているセッションが帰り道となり、ファイルを元に戻して再読み込みできます。物理的に到達できないサーバーでは、変更は一度に1つずつ行うべき理由もここにあります。壊れた鍵ファイルと無効化されたパスワード方式を同じ編集に入れると、帰り道がまったくなくなります。監査ツールは、あなたのファイルを基にした強化版を出発点として生成できますが、それはMatchブロックごとにレビューし、sshd -tでテストすべき下書きであり、未レビューで投入するファイルでは決してありません。