LinuxLinux [リナックス / ライナックス]オープンソースのOSカーネルサーバーのセキュリティ強化やポート番号変更などのために、SSHSSH [エスエスエイチ]Secure Shell。暗号化されたリモート接続プロトコルサーバーの設定ファイル(/etc/ssh/sshd_config)を変更したものの、「本当にこの設定で正しく動くのだろうか」「再起動した瞬間にリモート接続が切れて二度と入れなくなったらどうしよう」と不安を感じたことはありませんか?
この記事では、インフラエンジニアに向けて、sshd_configを変更した際に再起動前に設定の妥当性や内容を安全に確認・テストする方法を詳しく解説します。この記事を読むことで、設定ミスによる接続断(ロックアウト)のリスクを低減し、設定内容を確認したうえで安全に本番環境へ反映できるようになります。
確認した環境
本記事の検証およびコマンド実行確認は、以下の環境で行っています。
- OSOS [オーエス]Operating System。基本ソフトウェア: UbuntuUbuntu [ウブントゥ]人気のLinuxディストリビューション 22.04 LTS
- OpenSSH Server: 8.9p1系
sshd_configの設定確認が重要な理由
Linuxの運用管理において、SSHはリモートからサーバーを操作するためのライフラインです。設定ファイルを誤ったままサービスを再起動してしまうと、深刻なトラブルを引き起こす可能性があります。
SSH接続断(ロックアウト)のリスクを防ぐ
sshd_configにタイポ(入力ミス)があったり、利用できないディレクティブ(設定項目)が記述されていたりすると、SSHデーモン(sshd)の再起動に失敗するか、最悪の場合デーモン自体が起動しなくなります。
クラウド上の仮想マシンや、物理的に離れたデータセンターにあるサーバーでこれをやらかしてしまうと、コンソール(シリアルコンソールやIPMIなど)からの復旧作業が必要になり、多大な復旧コストが発生します。
設定変更後のトラブルを未然に防ぐ
OpenSSHのバージョンによって、サポートされている設定ディレクティブや値のフォーマットが異なる場合があります。変更内容が正しく解釈されるかを事前にテストすることで、「設定したはずなのに反映されていなかった」というミスの発生を防ぎます。
sshd_configの設定をテストするコマンド
設定ファイルを編集したら、まずは妥当性のテストを行いましょう。OpenSSHには、設定ファイルの構文エラーやホスト鍵の健全性を検知するための専用オプションが用意されています。
sshd -tコマンドの使い方とオプション
sshdコマンドに -t オプションを付与して実行すると、設定ファイルの妥当性チェック(Test mode)のみを行うことができます。構文エラーだけでなくホスト鍵の健全性も検証されるため、実際にサービスを再起動する前の安全確認として非常に有効です。
ただし、sshd -t はあくまで「設定ファイルとして正しく解釈できるか」を確認するものです。例えば PasswordAuthentication no は構文として正しくても、公開鍵認証の準備ができていない環境ではログインできなくなります。同様に、Port、AllowUsers、DenyUsers などの設定は構文が正しくても、実際の接続条件によってはアクセスできなくなる可能性があります。特にポート番号を変更した場合は、ファイアウォール(ufw / firewalld / クラウドのセキュリティグループ)やSELinuxの設定が追従していないと接続できなくなるため注意が必要です。そのため、後述する「新規セッションでの接続確認」が不可欠です。
sudo sshd -t通常の実行では、デフォルトの設定ファイル(通常は /etc/ssh/sshd_config)がテストされます。もし特定のファイルをテストしたい場合は、-f オプションでファイルパスを指定します。
sudo sshd -t -f /path/to/custom_sshd_configテストでエラーが出た場合の対処法
設定ファイルに問題がない場合、sudo sshd -t は何も出力せずに正常終了(終了コード 0)します。
一方、設定に誤りがある場合は、エラーメッセージと該当する行番号が出力されます。
$ sudo sshd -t/etc/ssh/sshd_config: line 45: Bad configuration option: PermitRootLoginng/etc/ssh/sshd_config: terminating, 1 bad configuration options上記の例では、45行目の PermitRootLoginng という存在しないディレクティブ名(スペルミス)が原因でエラーになっています。エラーメッセージに表示された行番号を頼りに /etc/ssh/sshd_config を修正し、再度 sudo sshd -t を実行してエラーが消えることを確認してください。
現在適用されている有効な設定値を確認する
「設定ファイルを書き換えたけれど、本当にその設定が有効になるのか?」「デフォルト値も含めて現在の全設定を確認したい」という場合には、-T オプションが非常に役立ちます。
sshd -Tコマンドで全設定をダンプする
sshd -T コマンド(Extended test mode)を実行すると、設定ファイルの妥当性チェックを行った上で、現在有効になっているすべての設定値(デフォルト値やインクルードされたファイルの設定を含む)を標準出力にダンプ(出力)します。
sudo sshd -Tこのコマンドを実行すると、以下のように大量の設定が出力されます。
usepam yespermitrootlogin nopasswordauthentication yesx11forwarding no...すべての設定が出力されるため、そのまま眺めるのではなく、次に紹介する grep コマンドと組み合わせるのが実用的です。
特定のパラメータをgrepで絞り込む方法
確認したい特定の設定項目がある場合は、grep を使って絞り込みます。sshd -T の出力では設定項目名(ディレクティブ名)がすべて小文字に正規化されるため、検索しやすくなっています。
例えば、PermitRootLogin の設定値を確認したい場合は次のように実行します。
sudo sshd -T | grep permitrootlogin出力結果例:
permitrootlogin noこれにより、コメントアウトされていたり、デフォルト値が適用されていたりする場合も含めて、現在の接続条件に応じた有効な設定値を確認できます。
Matchディレクティブ使用時の注意点
Match ディレクティブを使用して、接続するユーザーや送信元アドレスなどの条件によって設定を切り替えている場合、通常の sshd -T では特定の接続条件を指定した Match の評価結果を確認できません。
特定の接続条件に対して有効な設定を確認するには、-C オプションで接続条件を指定して実行します。
sudo sshd -T -C user=alice,addr=192.0.2.10,host=server-C オプションには user(ユーザー名)、addr(送信元IPIP [アイピー]Internet Protocol。インターネット通信の基本プロトコルアドレス)、host(ホスト名)などをカンマ区切りで指定します。Match ブロックの設定まで正確に確認したい場合は、このオプションを活用してください。
安全に設定を反映させる手順
ここまでの手順を踏まえて、本番環境のサーバーで安全に設定を変更・反映させるための実践的なステップを解説します。
ステップ1: 設定ファイルのバックアップを作成する
万が一の際にすぐ元の状態に戻せるよう、必ず設定ファイルのバックアップを作成します。
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak_$(date +%Y%m%d_%H%M%S)ファイル名に時刻まで含めることで、同じ日に複数回変更を行った場合でもバックアップが上書きされるのを防ぎます。
ステップ2: 設定ファイルを編集して保存する
テキストエディタ(vi や nano など)を使用して、目的の設定変更を行います。
sudo vi /etc/ssh/sshd_configステップ3: 妥当性テストを実施する
保存したら、必ず先ほど紹介した妥当性チェックコマンドを実行します。
sudo sshd -tここでエラーが出た場合は、サービスを再起動せず、エラーを修正して再度このテストを行ってください。
ステップ4: 既存セッションを維持したままサービスへ設定を反映
テストが正常にパスしたら、いよいよ設定を反映させます。ただし、インフラエンジニアの鉄則として、現在作業しているSSHセッションは絶対に閉じないまま、別ウィンドウ(別タブ)で新しいSSH接続テストを行える状態にしておきます。
設定変更の反映には、reload(設定の再読み込み)と restart(サービスの再起動)の2つの方法があります。設定変更の反映だけが目的であれば、reload を利用するとサービスを停止せずに設定を再読み込みできます。
Ubuntu / DebianDebian [デビアン]コミュニティ主導で開発される安定性の高いLinuxディストリビューションの場合:
# 設定の再読み込み(推奨)sudo systemctl reload ssh
# サービスの再起動(必要な場合)sudo systemctl restart sshRHEL / AlmaLinux / CentOSCentOS [セントオーエス]Red Hat Enterprise Linux互換の安定したLinuxディストリビューションの場合:
# 設定の再読み込み(推奨)sudo systemctl reload sshd
# サービスの再起動(必要な場合)sudo systemctl restart sshdOpenSSHは SIGHUP シグナルを受け取ると設定ファイルを再読み込みする仕組みになっており、systemctl reload はこの仕組みを利用しています。ただし、設定変更の内容やサービス構成によっては restart が必要なケースもあります。
ステップ5: 新規セッションでの接続確認
設定の反映後、現在作業している元のターミナルは閉じずに、お手元のローカル端末などから新しくSSH接続を試みます。
無事にログインできることを確認できたら、設定変更作業は完了です。万が一、新しいセッションで接続できない場合は、閉じずに残しておいた元のセッションから以下の手順で復旧を行います。
# バックアップから設定ファイルを復元sudo cp /etc/ssh/sshd_config.bak_YYYYMMDD_HHMMSS /etc/ssh/sshd_config
# 復元した設定ファイルの妥当性を確認sudo sshd -t
# 設定を再読み込みsudo systemctl reload sshまとめ
LinuxのSSHサーバー設定(sshd_config)を変更する際は、以下のポイントを押さえることで、接続断などの重大なインシデントを防ぐことができます。
- 設定変更後は必ず
sudo sshd -tで設定ファイルの妥当性テストを行う - 現在の有効な設定値を確認したいときは
sudo sshd -Tとgrepを組み合わせる - サービスを再起動する前に、必ずバックアップを取得する
- サービスへの設定反映後も既存のセッションを維持したまま、新しいセッションで接続確認を行う
これらの手順をルーティン化することで、安全かつ確実なサーバー管理を実現しましょう。
以上で本記事の解説を終わります。
よいITライフを!
人気記事
- 1
- 2
- 3
- 4
- 5
Rocky Linux対応。実際にWebサーバーを公開するまでのプロセスを体験できる、最も確実で実践的なガイドブックです。