2026年5月20日
2026年5月20日
WordPressサーバーのSSHを安全にする|公開鍵認証・パスワード無効化・Fail2ban
VPS やクラウドのサーバーに WordPress を置いている場合、SSH はサーバーを管理する主な入り口です。インターネットに公開された SSH には、パスワードを総当たりで試すログイン試行が絶えず届きます。パスワードでログインできる状態のままだと、弱いパスワードのアカウントから侵入されるおそれがあります。
この記事では、SSH を公開鍵認証だけにし、root での直接ログインを禁止し、ファイアウォールと Fail2ban で試行を減らす手順を説明します。コマンドやパスは2026年10月時点の Ubuntu 24.04 を例にしています。レンタルサーバーの SSH 機能は設定ファイルを変えられないことが多いため、ここでは自分で管理する VPS・クラウドのサーバーを対象にします。
作業中に設定を誤ると、SSH でログインできなくなることがあります。いま接続している SSH のセッションは閉じずに残し、別のターミナルで新しい接続を試してから次へ進んでください。万一のため、事業者の管理画面からサーバーのコンソールを開く方法も確認しておきます。
1. 現在の状況を確認する
まず、ログイン試行が来ているかと、現在の SSH の設定を確認します。ログは journalctl で見ると、ディストリビューションによるログファイルの違いや時刻の書式を気にせずに済みます(Ubuntu ではサービス名が ssh、RHEL 系では sshd)。
# 過去24時間のパスワード認証の失敗
sudo journalctl -u ssh --since "24 hours ago" | grep -c "Failed password"
# 存在しないユーザー名での試行
sudo journalctl -u ssh --since "24 hours ago" | grep "Invalid user" | tail -n 10
# 試行の多い接続元IPアドレス
sudo journalctl -u ssh --since "24 hours ago" \
| grep -oE "Failed password .* from [0-9.]+" \
| awk '{print $NF}' | sort | uniq -c | sort -rn | head -n 10
# 実際に有効になっている設定(設定ファイルをすべて読んだ結果)
sudo sshd -T | grep -iE "^(port|permitrootlogin|passwordauthentication|kbdinteractiveauthentication|pubkeyauthentication) "
2. 公開鍵認証を設定する
自分の PC(クライアント)で鍵のペアを作り、公開鍵をサーバーに登録します。Windows 10・11 の PowerShell でも同じ ssh-keygen が使えます。
# 自分のPCで実行。パスフレーズを設定する
ssh-keygen -t ed25519 -C "wordpress-server" -f ~/.ssh/wordpress_key
# ~/.ssh/wordpress_key 秘密鍵(他人に渡さない)
# ~/.ssh/wordpress_key.pub 公開鍵(サーバーに登録する)
# 公開鍵をサーバーに登録(この時点ではパスワードでログインする)
ssh-copy-id -i ~/.ssh/wordpress_key.pub deploy@203.0.113.10
ssh-copy-id が無い環境(Windows など)では、公開鍵の中身をサーバーの ~/.ssh/authorized_keys に追記します。
# サーバー側で実行(公開鍵の1行を貼り付ける)
mkdir -p ~/.ssh && chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
鍵でログインできることを確認します。ここで失敗する場合は、次の手順に進まないでください。
ssh -i ~/.ssh/wordpress_key deploy@203.0.113.10
毎回の指定を省くため、自分の PC の ~/.ssh/config に接続先を登録しておくと便利です。
Host wordpress-server
HostName 203.0.113.10
User deploy
IdentityFile ~/.ssh/wordpress_key
IdentitiesOnly yes
以後は ssh wordpress-server で接続できます。
3. パスワード認証とrootログインを無効にする
Ubuntu の /etc/ssh/sshd_config は、先頭で Include /etc/ssh/sshd_config.d/*.conf を読み込みます。sshd は同じ項目が複数回出てきたとき、最初に読んだ値を使うため、sshd_config.d に置いたファイルの設定が本体より優先されます。クラウドのイメージでは、このフォルダーに PasswordAuthentication yes を書いたファイルが置かれていることがあるので、名前順で先に読まれる名前で設定ファイルを作ります。
ls /etc/ssh/sshd_config.d/
sudo nano /etc/ssh/sshd_config.d/00-hardening.conf
# /etc/ssh/sshd_config.d/00-hardening.conf
# 公開鍵認証だけを許可する
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no
# root での直接ログインを禁止する(作業は一般ユーザー+sudo で行う)
PermitRootLogin no
# 1接続あたりの認証の試行回数と、ログインまでの待ち時間
MaxAuthTries 3
LoginGraceTime 30
# 使わない機能を止める
X11Forwarding no
# ログインできるユーザーを限定する場合(ユーザー名は自分の環境に合わせる)
# AllowUsers deploy
- 以前の記事でよく見る
ChallengeResponseAuthenticationは、OpenSSH 8.7 でKbdInteractiveAuthenticationに名前が変わり、古い名前は互換のための別名として残っているだけです。新しい名前で書きます AllowUsersを有効にすると、書いたユーザー以外は SSH でログインできなくなります。SFTP で WordPress のファイルを更新するユーザーがいれば、そのユーザーも含めます
設定の構文を確認し、実際に有効になる値を確かめてから、SSH を再起動します。
sudo sshd -t
sudo sshd -T | grep -iE "^(permitrootlogin|passwordauthentication|kbdinteractiveauthentication) "
sudo systemctl restart ssh
再起動したら、今のセッションを閉じずに別のターミナルから鍵でログインできることを確認します。あわせて、パスワードでのログインが拒否されることも確かめます。
# 鍵での接続(成功するはず)
ssh wordpress-server
# パスワードでの接続を試す(Permission denied (publickey) になるはず)
ssh -o PubkeyAuthentication=no deploy@203.0.113.10
4. ポートを変更する場合(任意)
SSH のポートを 22 以外にすると、22 番を狙う自動の試行はログから大きく減ります。ただし、公開鍵認証にしていれば、ポート変更による安全性の上積みは大きくありません。変える場合は、手順の順番に注意します。
- ファイアウォールで新しいポートを先に開ける
- SSH の待ち受けポートを変える
- 新しいポートで接続できることを確認してから、22 番を閉じる
# 1. ufw を使っている場合
sudo ufw allow 2222/tcp
# 2. /etc/ssh/sshd_config.d/00-hardening.conf に追加
Port 2222
Ubuntu 22.10 以降(24.04 を含む)は、SSH がソケット起動(ssh.socket)で動いており、待ち受けるポートは ssh.socket が持っています。Port を変えたら、ssh サービスの再起動だけでは反映されないため、次のように設定を読み直してソケットを再起動します。
sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
# 新しいポートで待ち受けているか確認
sudo ss -tlnp | grep -E ":(22|2222) "
# 3. 別のターミナルで新しいポートに接続できたら、22番を閉じる
ssh -p 2222 wordpress-server
# 22番を許可しているルールの番号を確認して削除する
sudo ufw status numbered
sudo ufw delete 番号
~/.ssh/config を使っている場合は Port 2222 を追記します。クラウドのセキュリティグループ(AWS など)や、事業者のファイアウォール機能を使っている場合は、そちらでも新しいポートを許可します。RHEL 系では SELinux の許可(semanage port -a -t ssh_port_t -p tcp 2222)と firewalld の設定も必要です。
5. ファイアウォールで接続元を絞る
管理に使う接続元の IP アドレスが決まっているなら、SSH をその IP アドレスからだけ受け付けるのが最も効果的です。ufw の例です(ポートは自分の設定に合わせます)。
# 事務所の固定IPからだけSSHを許可する
sudo ufw allow from 198.51.100.0/24 to any port 22 proto tcp
# Webは全体に公開
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status numbered
ufw enable の前に、SSH を許可するルールが入っていることを確認してください。クラウドのサーバーでは、事業者のセキュリティグループで同じ制限をかけることもできます。
6. Fail2banで試行を繰り返すIPを遮断する
接続元を絞れない場合は、Fail2ban で、認証に何度も失敗した IP アドレスを一定時間遮断します。
sudo apt install fail2ban
sudo nano /etc/fail2ban/jail.local
[sshd]
enabled = true
# ポートを変えていれば合わせる(例: port = 2222)
port = ssh
maxretry = 5
findtime = 10m
bantime = 1h
# 自分の接続元は遮断しない
ignoreip = 127.0.0.1/8 ::1 198.51.100.0/24
ログの読み取り方法はパッケージの既定に任せます。/var/log/auth.log が無い環境(rsyslog を入れていない Debian 12 など)で Fail2ban が起動しない場合は、[sshd] に backend = systemd を追加します。
sudo systemctl enable --now fail2ban
sudo systemctl restart fail2ban
# 状態と遮断中のIPを確認
sudo fail2ban-client status sshd
# 誤って遮断したIPを解除
sudo fail2ban-client set sshd unbanip 198.51.100.25
7. 鍵とアカウントを管理する
- 秘密鍵にはパスフレーズを付け、PC の外に出さない。チームで共有せず、1人1つの鍵を使う
- 退職や PC の紛失があれば、サーバーの
~/.ssh/authorized_keysから該当する公開鍵の行を削除する - WordPress のファイルを更新するユーザーと、サーバーを管理する(sudo が使える)ユーザーを分ける
- OpenSSH を含め、
sudo apt update && sudo apt upgradeでサーバーのパッケージを最新に保つ
まとめ
ssh-keygen -t ed25519で鍵を作り、公開鍵を登録して、鍵でログインできることを確認する/etc/ssh/sshd_config.d/00-hardening.confにPasswordAuthentication no・KbdInteractiveAuthentication no・PermitRootLogin noを書き、sshd -Tで有効な値を確かめる- 設定を変えたら、今のセッションを残したまま別のターミナルで接続を確認する
- Ubuntu 24.04 でポートを変えるときは、
daemon-reloadとssh.socketの再起動が必要。ファイアウォールで新しいポートを先に開ける - 接続元を固定できるならファイアウォールで絞り、できなければ Fail2ban で遮断する
関連記事: