SSHログ点検2026年8月版｜今すぐ締めるべき設定3つ

「うちのサーバーのSSH設定、このままで大丈夫だろうか」と不安なまま放置していませんか。VPSを公開すると数分後にはSSHへの総当たり攻撃が始まり、24時間止まりません。本記事ではUbuntu/Debianのjournalctl -u sshやauth.logでログイン試行を点検し、PasswordAuthentication・PermitRootLogin・鍵認証の設定漏れを実際のコマンドと出力例で見分けて、今すぐ締めるべきSSH設定を洗い出す手順を初心者向けに解説します。

「うちは狙われていない」は通用しない｜24時間で38,000件超の攻撃観測

2026年4月17日に行われた国内の観測では、SSHポートを開放したVPSを24時間放置しただけで38,000件超のSSH攻撃試行が記録され、公開から数分で攻撃が始まり、その後も休みなく続いたと報告されています。攻撃元IPの上位には中国・米国・カナダなどが並び、日本国内からの攻撃も95件確認されています。JPCERT/CCもSSHへの攻撃動向について継続的に注意喚起を行っており、「狙われていないサーバー」は存在しない前提で点検する必要があります。

すでに攻撃を受けた形跡があるかどうかをログから具体的に確認する手順は、以下の記事で詳しく扱っています。まず今回の記事で設定の穴を塞いだうえで、こちらも合わせて確認してください。

SSH総当たり攻撃の形跡をログで確認【26年8月】

journalctl -u ssh / auth.log でログイン試行を点検する

Ubuntu・Debianのログの見方の違い

Ubuntu・Debianはどちらもsshdのサービス名がsshで統一されています（RHEL系のsshdとは名前が異なるので注意）。ログはsystemdのジャーナル（journalctl）と、rsyslogが書き出す/var/log/auth.logの2箇所で確認できます。journalctlの保存期間が短く設定されている環境や、journalの永続化（persistent journal）が無効な環境では過去ログが消えていることがあるため、両方を確認する習慣をつけてください。

sudo journalctl -u ssh --since "24 hours ago" | grep "Failed password"

これは「直近24時間のSSHログイン失敗」を見ています。出力例は次の通りです。

Aug 18 03:12:41 myserver sshd[12345]: Failed password for root from 185.220.101.4 port 51322 ssh2
Aug 18 03:12:44 myserver sshd[12345]: Failed password for invalid user admin from 185.220.101.4 port 51330 ssh2

見るポイント：root fromで始まる行が大量にあれば、rootに対する総当たり攻撃を受けています。invalid userは存在しないユーザー名を試している行で、これも自動化された攻撃の典型パターンです。数件程度なら日常的なノイズですが、同一IPから数百〜数千件並ぶ場合は次章の設定点検が急務です。

journalctlで何も出ない、または短期間しか遡れない場合はauth.logを直接見ます。

sudo grep "Failed password" /var/log/auth.log | tail -20
sudo grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -10

2つ目のコマンドは「失敗回数が多いIPアドレスの上位10件」を集計しています。1つのIPから数百件を超えていれば、そのIPは総当たり攻撃の発信元とみなして問題ありません（この後の対策で自動的に遮断対象になります）。

ログイン成功の行も必ず確認する

sudo journalctl -u ssh --since "24 hours ago" | grep "Accepted"

これは「実際にログインが成功した記録」です。Accepted password（パスワード認証で成功）やAccepted publickey（鍵認証で成功）に続けてユーザー名とIPが表示されます。心当たりのないIPやユーザー名でこの行があれば、既に侵入されている可能性があるため、即座にそのユーザーのパスワード変更・鍵の失効・サーバー内の不審なプロセスやポートの確認（後述リンク参照）を行ってください。

sshd -T で「今すぐ締めるべき設定」を洗い出す

/etc/ssh/sshd_configを目視で確認するだけでは、/etc/ssh/sshd_config.d/以下の追加設定ファイル（Includeで読み込まれる）で値が上書きされていても気づけません。実際に有効になっている設定値をまとめて出力するsshd -Tを使うのが確実です。

sudo sshd -T | grep -iE "passwordauthentication|permitrootlogin|pubkeyauthentication"

これは「現在サーバーに実際に反映されているSSH認証設定」を見ています。出力例は次の通りです。

passwordauthentication yes
permitrootlogin yes
pubkeyauthentication yes

項目	危険な状態	推奨値	意味
passwordauthentication	yes	no	パスワードだけでログインできる状態。総当たり攻撃が理論上いつか突破できてしまう
permitrootlogin	yes	prohibit-password（またはno）	rootに直接パスワードでログインできる状態。突破されると即管理者権限を奪われる
pubkeyauthentication	no	yes	鍵認証が無効。パスワード以外のログイン手段がなくなる

Ubuntuの初期設定ではpermitrootloginはprohibit-password（パスワードでのroot直接ログインのみ禁止、鍵があれば可）になっていることが多いですが、過去にrootで作業した際に手動でyesへ書き換えてそのまま忘れている、という漏れが実務では頻発します。まずは上記コマンドの出力を確認し、表の「危険な状態」に該当する項目がないかをチェックしてください。

設定変更の手順とロールバック方法

ここでの変更はsudo権限が必須で、SSHでの接続方法そのものに影響する設定変更です。誤ると自分がサーバーに入れなくなる（ロックアウトされる）リスクがあるため、必ず以下の順序で進めてください。

先に鍵認証でログインできる状態を作っておく（ssh-copy-id等で公開鍵を登録し、鍵だけでログインできることを別のターミナルで確認する）
設定ファイルをバックアップする：sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak_20260818
sudo nano /etc/ssh/sshd_configで該当行を編集する（PasswordAuthentication no・PermitRootLogin prohibit-password）
構文エラーがないか事前確認する：sudo sshd -t（これはエラーが出力されなければ正常。エラーが出た場合は反映されないので安全）
反映する：sudo systemctl restart ssh
今開いているターミナルは閉じずに、別のターミナルから新規に接続テストを行う

接続できなくなった場合は、VPS事業者のコンソール機能（ブラウザ経由でのシリアルコンソール等、SSHを経由しない管理画面）からログインし、バックアップした設定に戻します。

sudo cp /etc/ssh/sshd_config.bak_20260818 /etc/ssh/sshd_config
sudo systemctl restart ssh

バックアップさえ取っておけば、いつでも元の状態に戻せます。

ポート変更と鍵認証の効果、OpenSSH本体のアップデートも忘れずに

ポート変更は手軽ながら効果が大きい

SSHのポート番号（デフォルト22番）を別の番号に変更するだけで、多くの攻撃はポート22を狙う自動スクリプトのため発見されにくくなり、ブルートフォース攻撃によるBAN件数が99%減少したという検証結果もあります。設定は/etc/ssh/sshd_configのPort行を変更し、ファイアウォール（ufwを使っている場合はsudo ufw allow 新ポート番号/tcp）を新ポートに合わせて更新してからsystemctl restart sshで反映します。変更後、実際にどのポートで待ち受けているかは以下の記事のコマンドで確認できます。

ss -tulpn/lsof -iで不審ポート点検【26年8月】

OpenSSH本体も定期的に更新する

OpenSSHは2026年8月11日に最新版10.5/10.5p1をリリースし、複数のセキュリティ修正が含まれています。開発チームはAIによる脆弱性発見の増加を受けてリリース頻度を上げる方針を示しており、今後もこまめな更新が必要になります。現在のバージョンはssh -Vで確認でき、アップデートは設定ファイルを触らない通常のパッケージ更新で完了します。

ssh -V
sudo apt update
sudo apt upgrade openssh-server

これは既存の設定を変更するものではなく元に戻す操作も不要ですが、念のため更新後はsudo systemctl status sshでサービスが正常に起動しているかを確認してください。なお、Debian 11（Bullseye）はLTSサポートが2026年8月31日で終了するため、まだ移行していない場合はOSごとのアップグレードも合わせて計画してください。

まとめ

SSHは公開直後から数分で攻撃対象になり、24時間攻撃が止まらないのが実態です。まずjournalctl -u sshとauth.logで失敗・成功の記録を確認し、sudo sshd -TでPasswordAuthentication・PermitRootLoginの現在値を洗い出してください。鍵認証への切り替え・ポート変更・OpenSSHの更新はどれも手軽な割に効果が大きい対策です。変更前のバックアップと、鍵認証の事前確認さえ徹底すれば、初心者でも安全に締められます。