新しく用意した Linux サーバーは、公開した直後から SSH へのログイン試行などを受け始めます。最初の作業として「パッケージを最新にして自動更新を有効にする」「作業用ユーザーを作り、SSH を鍵認証だけにして root ログインを止める」「ファイアウォールで必要なポートだけを開ける」の3点を済ませると、自動化された総当たりなどのよくある攻撃に対する土台ができます。この記事では、構築直後に上から順に進められるチェックリストとして、Ubuntu 系と RHEL 系（AlmaLinux、Rocky Linux など）のコマンドと、設定が効いているかの確認方法をまとめます。
コマンドやパッケージ名、設定ファイルの場所はディストリビューションとバージョンで違いがあります（2026年10月現在）。ここでは Ubuntu 22.04 / 24.04 と RHEL 9 系を想定しています。自分の環境の公式ドキュメントと照らし合わせて読み替えてください。
作業を始める前の準備
SSH の設定を変える作業では、設定を誤ると自分もログインできなくなります。始める前に次の2つを確認します。
- 復旧手段：クラウドや VPS の管理画面にある、ブラウザから使えるコンソール（シリアルコンソールや VNC コンソールなど）の場所を確認しておきます。SSH に入れなくなったとき、ここから設定を戻せます。
- スナップショット：構築直後でもサーバーのスナップショットを取っておくと、設定を誤ったときに最初からやり直せます。
また、SSH の設定を変えるときは、今つないでいるセッションを閉じずに、別の端末から新しく接続できることを確かめてから閉じます。
1. パッケージを最新にする
最初に、インストール済みのパッケージを更新します。配布されたイメージは作成時点のもので、公開済みの脆弱性が修正されていないことがあります。
# Ubuntu / Debian
sudo apt update && sudo apt full-upgrade -y
# RHEL 9 系（AlmaLinux / Rocky Linux など）
sudo dnf upgrade -yカーネルが更新された場合は再起動して反映させます。Ubuntu では /var/run/reboot-required というファイルがあれば再起動が必要です。
2. セキュリティ更新を自動で適用する
更新を人手だけに頼ると、忙しい時期に放置されがちです。セキュリティ更新だけでも自動で入るようにしておきます。
# Ubuntu：unattended-upgrades を有効にする
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades
# RHEL 9 系：dnf-automatic を使う
sudo dnf install -y dnf-automatic
# /etc/dnf/automatic.conf で upgrade_type = security、apply_updates = yes にしてから
sudo systemctl enable --now dnf-automatic.timer自動更新はアプリケーションに影響する可能性もあるため、本番では更新の記録（Ubuntu なら /var/log/unattended-upgrades/）を定期的に確認し、再起動が必要な更新は日時を決めて反映します。
3. 作業用ユーザーを作り、sudo を使えるようにする
root で直接作業するのをやめ、自分専用のユーザーから必要なときだけ sudo を使うようにします。誰がいつ管理者権限を使ったかがログに残るようにするためです。
# Ubuntu
sudo adduser deploy
sudo usermod -aG sudo deploy
# RHEL 9 系
sudo useradd -m deploy
sudo passwd deploy
sudo usermod -aG wheel deploydeploy は例なので、推測されにくい名前に置き換えてください。sudo の実行時に使うパスワードは、ほかで使っていない長いものにします。
4. SSH を鍵認証にする
手元の PC で鍵を作り、公開鍵をサーバーの作業用ユーザーに登録します。
# 手元の PC で実行
ssh-keygen -t ed25519 -C "deploy@example-server"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10
ssh deploy@203.0.113.10 # パスワードを聞かれずに入れるか確認秘密鍵にはパスフレーズを付け、サーバーやほかの人と共有しないようにします。
5. root ログインとパスワード認証を止める
鍵でログインできることを確かめたら、SSH の設定を絞ります。最近のディストリビューションでは /etc/ssh/sshd_config から /etc/ssh/sshd_config.d/ 配下のファイルを読み込む構成になっているため、そこに自分用のファイルを作ります。
# /etc/ssh/sshd_config.d/10-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
AllowUsers deployここでつまずきやすいのがファイルの読み込み順です。sshd は多くの設定項目で「最初に読み込んだ値」を採用します。クラウドのイメージでは、cloud-init が作る 50-cloud-init.conf に PasswordAuthentication yes が書かれていることがあり、自分のファイルがそれより後に読まれると設定が効きません。ファイル名を 10- のように若い番号で始めるのはそのためです。
設定を反映する前に、構文の確認と、実際に有効になる値の確認をします。
sudo sshd -t # 構文エラーが無ければ何も表示されない
sudo sshd -T | grep -Ei 'permitrootlogin|passwordauthentication|allowusers'
sudo systemctl reload ssh # RHEL 系はサービス名が sshdreload の後、今のセッションを開いたまま、別の端末から ssh deploy@サーバー で入れることを確認します。あわせて、パスワード認証が拒否されることも確かめておくと安心です（ssh -o PubkeyAuthentication=no deploy@サーバー で、パスワードを聞かれずに拒否されれば有効です）。
SSH のポート番号を変える方法もありますが、攻撃の記録が減る程度の効果で、鍵認証の代わりにはなりません。変える場合、Ubuntu の新しいバージョンでは SSH がソケット起動（ssh.socket）になっていて、待ち受けポートの変え方が従来と異なることがある点に注意します。
6. ファイアウォールで必要なポートだけを開ける
既定で外からの通信をすべて拒否し、使うサービスだけを許可します。SSH を許可する前に有効にすると切断されるので、順番を守ります。
# Ubuntu（ufw）
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp # Web サーバーの場合
sudo ufw enable
sudo ufw status verbose
# RHEL 9 系（firewalld）
sudo firewall-cmd --permanent --add-service=http --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-allクラウドではセキュリティグループなど、サーバーの外側のファイアウォールもあります。両方で絞っておくと、片方の設定を誤ったときの保険になります。SSH は、可能であれば接続元の IP アドレスを自分の拠点に限定します。
7. ログイン試行を自動でブロックする（Fail2ban）
鍵認証にしても、総当たりの試行はログを埋め、負荷にもなります。Fail2ban は、ログイン失敗を繰り返した IP アドレスを一定時間ブロックします。
# /etc/fail2ban/jail.local
[sshd]
enabled = true
maxretry = 5
findtime = 10m
bantime = 1hsudo systemctl enable --now fail2ban
sudo fail2ban-client status sshdログをファイルではなく journald にだけ記録する環境では、jail に backend = systemd の指定が必要になることがあります。RHEL 系では EPEL リポジトリから入れるのが一般的です。自分の IP アドレスがブロックされないよう、ignoreip に管理元のアドレスを入れておく方法もあります。
8. 動いているサービスと待ち受けポートを確認する
不要なサービスが外からの通信を待ち受けていないかを確認します。
sudo ss -tulpn
systemctl list-unit-files --type=service --state=enabled0.0.0.0 や [::] で待ち受けているものが、外部に公開してよいサービスかを1つずつ確かめます。データベースのように同じサーバー内からしか使わないものは、127.0.0.1 だけで待ち受けるように設定し、使っていないサービスは sudo systemctl disable --now サービス名 で止めます。
9. SELinux / AppArmor を有効のままにする
RHEL 系の SELinux、Ubuntu の AppArmor は、プロセスが触れるファイルや操作を制限する仕組みです。アプリケーションが動かない原因になると無効にしてしまいがちですが、侵入されたときの被害を抑える層なので、有効のまま必要な許可を追加する方針にします。
getenforce # RHEL 系：Enforcing なら有効
sudo aa-status # Ubuntu：読み込まれているプロファイルを表示SELinux で拒否された操作は /var/log/audit/audit.log に記録されるので、原因を確かめてから設定を調整します。
10. 時刻同期・ログ・バックアップを整える
- 時刻同期：
timedatectlで「System clock synchronized: yes」になっているかを確認します。時刻がずれていると、ログの照合や証明書の検証で問題が起きます。 - ログ：
journalctl -u ssh（RHEL 系は-u sshd）や/var/log/auth.log（RHEL 系は/var/log/secure）で、ログインの記録を確認できるようにしておきます。必要に応じて auditd で重要ファイルへの操作を記録します。 - バックアップ：設定が終わった時点でスナップショットを取り、データのバックアップも定期的に取るようにします。
まとめ
- 始める前に、管理画面のコンソールとスナップショットという復旧手段を用意し、SSH の設定変更中は今のセッションを閉じないようにします。
- パッケージを更新し、セキュリティ更新を自動で適用する設定にします。
- 作業用ユーザーで sudo を使い、SSH は鍵認証だけにして root ログインを止めます。
sshd_config.dの読み込み順に注意し、sshd -Tで有効な値を確認します。 - ファイアウォールは既定で拒否し、必要なポートだけを開けます。Fail2ban でログイン試行をブロックします。
- 待ち受けポートを確認して不要なサービスを止め、SELinux / AppArmor は有効のまま運用します。