Ubuntuサーバーを立てて数日後、「SSHのログに知らないIPからのログイン失敗が大量に並んでいる。これは攻撃されているのか、もう侵入されてしまったのか」と不安になったことはないでしょうか。結論から言うと、公開サーバーへのSSH総当たり攻撃（パスワードを片っ端から試す自動攻撃）はほぼ全員が受けています。大事なのは、それが「よくある自動スキャン」なのか「侵入された疑い」なのかをログから見分けることです。この記事ではjournalctl -u sshとlastbを使い、どこを見て何を数えれば判別できるのかを、出力例つきで解説します。

まず前提：SSHへの総当たりは「異常」ではなく「常態」

2026年時点の調査では、Linuxシステムに対する攻撃活動のうち89%がSSHエンドポイントに集中しているとされています。新しいVPSが公開IPアドレスを受け取ってから数分以内にポートスキャンが始まるのは常態化しており、あるHetznerのVPSでは最初の1時間でrootパスワードの試行が400回以上記録されたという事例も報告されています。

つまり「ログイン失敗が並んでいる」こと自体は、あなたのサーバーが特別に狙われている証拠にはなりません。IPAをはじめとする公的機関が2026年も境界型機器・SSHへの不正アクセスを注意喚起し続けているのは、この常時攻撃を前提に設定と点検をしているかが分かれ目になるためです。

この記事で見分けたいのは、次の3段階のどこにいるかです。

段階

ログに出る特徴

やること

① 自動スキャン（ほぼ全サーバー）

失敗だけが延々と続く。存在しないユーザー名が多い

設定を確認して放置でよい

② 標的化の兆候

実在するユーザー名に絞って試行が続く

設定を締める・IP制限を検討

③ 侵入の疑い

失敗の連続のあとに成功が混ざる

直ちに調査。後述の手順へ

ポイントはシンプルで、「成功したログインが、身に覚えのあるものだけか」を確認することに尽きます。失敗の件数そのものは、実はあまり判断材料になりません。

journalctl -u ssh でSSHログを読む：失敗と成功の数え方

Ubuntu 24.04では、SSHサーバー（sshd）のログはsystemdのジャーナル（システムのログを一元管理する仕組み）に入ります。以前の/var/log/auth.logを直接読む方法も生きていますが、サービス単位で絞れるjournalctlのほうが扱いやすいです。

直近1週間の失敗ログを見る

これから使うコマンドはすべて読み取り専用で、設定は一切変更しません。安心して実行してください。sudoは必要です（他人のログイン記録を含むため、一般ユーザーでは全体が見えません）。

sudo journalctl -u ssh --since "7 days ago" | grep "Failed password" | tail -20

このコマンドは「SSHサービスのログのうち、パスワード認証に失敗した行を直近20件だけ表示」しています。出力はこうなります。

Aug 14 03:12:44 myserver sshd[10233]: Failed password for invalid user admin from 45.***.***.12 port 51422 ssh2
Aug 14 03:12:47 myserver sshd[10235]: Failed password for invalid user test from 45.***.***.12 port 51488 ssh2
Aug 14 03:12:51 myserver sshd[10237]: Failed password for root from 45.***.***.12 port 51502 ssh2
Aug 14 03:12:55 myserver sshd[10239]: Failed password for invalid user oracle from 45.***.***.12 port 51560 ssh2

ここで見るべきはinvalid userという文字列です。これは「そのユーザー名はこのサーバーに存在しない」という意味で、admin・test・oracle・ubuntuのような、どのサーバーにもいそうな名前が並んでいれば辞書を上から順に試しているだけの自動スキャンです。①の段階であり、慌てる必要はありません。

逆に注意したいのは、invalid userが付かない失敗です。上の例の3行目Failed password for root from ...のように、実在するユーザー名（rootや、あなたが作ったkazのような名前）が繰り返し出ている場合は、ユーザー名を知られている＝②の段階の可能性があります。

攻撃元IPを件数順に数える

sudo journalctl -u ssh --since "7 days ago" | grep "Failed password" \
  | grep -oE "from [0-9.]+" | sort | uniq -c | sort -rn | head -10

これは「失敗ログからIPアドレスだけを抜き出し、多い順に上位10件を数える」コマンドです。

   3812 from 45.***.***.12
   1204 from 193.***.***.87
    866 from 61.***.***.203
      4 from 203.***.***.5

判断の目安はこうです。

  • 数千件が数個のIPに集中している → 典型的なボットです。放置しても問題ありませんが、後述のfail2banで自動遮断すればログが静かになります
  • 数件〜十数件だけのIPが多数ある → 分散型のゆるいスキャンです。これも通常運転の範囲
  • 心当たりのあるIP（自宅や職場）が上位にいる → 自分の設定ミス（古いパスワードを保存したクライアント等）の可能性が高いです

いちばん重要：成功したログインを全部見る

この記事で唯一「必ず実行してほしい」のがこのコマンドです。

sudo journalctl -u ssh --since "30 days ago" | grep "Accepted"

「認証に成功した（Accepted）ログイン記録を過去30日分すべて表示」します。失敗が何万件あっても、成功が自分のものだけなら侵入はされていません。

Aug 10 09:02:11 myserver sshd[2044]: Accepted publickey for kaz from 192.168.1.20 port 54120 ssh2: ED25519 SHA256:xxxx
Aug 12 21:44:08 myserver sshd[7781]: Accepted publickey for kaz from 192.168.1.20 port 60233 ssh2: ED25519 SHA256:xxxx

正常な状態の見分け方は次の3点です。

  1. Accepted publickeyになっている（鍵認証で入っている）。ここがAccepted passwordだらけなら、パスワードでのログインが有効なままです
  2. ユーザー名が自分の作ったものだけ。Accepted ... for rootや見覚えのない名前があれば要調査
  3. 接続元IPに心当たりがある。自宅・職場・VPNの範囲かどうか

逆に危険信号は「失敗が大量に続いた直後に、同じIPからAcceptedが出ている」パターンです。これは総当たりが成功した可能性を示します。この場合の対応は後半にまとめます。

ディストリビューションによる差

環境

サービス名

備考

Ubuntu 24.04 / 26.04

ssh

本記事の基準。sshdでも別名として通ることが多い

Debian 13 (Trixie)

ssh

Ubuntuと同じ。13.6が2026年7月11日リリース

RHEL / Rocky / AlmaLinux

sshd

journalctl -u sshdと書き換える

-u sshで何も出ない場合は、sudo journalctl -u sshdを試してください。それでも空ならsystemctl status ssh sshdでサービス名を確認します。

lastb で失敗ログインの一覧を時系列で確認する

lastbはログイン失敗の記録（/var/log/btmp）を新しい順に一覧表示するコマンドです。journalctlがテキストログを追うのに対し、こちらは専用の記録ファイルを読むため、集計向きで見やすいのが利点です。

sudo lastb | head -20

これも読み取り専用です。出力例は次のようになります。

admin    ssh:notty    45.***.***.12    Fri Aug 14 03:12 - 03:12  (00:00)
test     ssh:notty    45.***.***.12    Fri Aug 14 03:12 - 03:12  (00:00)
root     ssh:notty    193.***.***.87   Thu Aug 13 22:40 - 22:40  (00:00)

左からユーザー名・接続方式・接続元IP・日時です。ssh:nottyは「端末を割り当てられていないSSH接続」という意味で、自動化されたログイン試行では普通に出ます。

失敗の総数と、狙われたユーザー名を数える

sudo lastb | wc -l

「記録されている失敗の総行数」です。数千〜数万でも公開サーバーなら珍しくありません。次に、どのユーザー名が狙われたかを数えます。

sudo lastb | awk '{print $1}' | sort | uniq -c | sort -rn | head -10
  12043 root
   3320 admin
   1877 ubuntu
   1204 test
      2 kaz

ここでの判断は明快です。

  • root・admin・test・ubuntu・postgresなど汎用名ばかり → 辞書ベースの自動攻撃。①の段階
  • あなたが実際に作った固有のユーザー名が上位に来ている → ユーザー名が特定されている②の段階。攻撃者が推測でたどり着くこともありますが、鍵認証への切り替えを優先すべきサインです

btmpは自動でローテーションされる点に注意

lastbが見ている/var/log/btmpはlogrotateによって定期的に切り替えられるため、古い記録はbtmp.1に移っています。過去にさかのぼりたい場合は次のように指定します。

sudo lastb -f /var/log/btmp.1 | head -20

なお、lastbが「そのようなファイルはありません」と返す環境もあります。/var/log/btmpが存在しない場合は失敗記録が取られていない状態なので、journalctl側で確認してください（ファイルを手動で作る必要は特にありません。journalctlで足ります）。

lastb（失敗）とlast（成功）はセットで見る

last -20

lastは成功したログインの履歴を表示します（こちらはsudo不要な環境が多いです）。rebootの行はサーバー再起動の記録なので気にしなくて構いません。ここに見覚えのないユーザー・IPが並んでいないかを確認します。journalctlのAcceptedと合わせて、成功記録を二重に確認できます。

「侵入された疑い」を判定する3つのチェックと、その次の行動

上記で成功ログインに違和感があった場合、あるいは念のため確認したい場合の手順です。すべて読み取り専用のコマンドで、設定は変更しません。

チェック1：知らないユーザーが増えていないか

awk -F: '$3 >= 1000 && $3 「一般ユーザー（UID 1000以上）の一覧を、名前・UID・ログインシェルで表示」します。

kaz 1000 /bin/bash

自分が作った覚えのあるユーザーだけなら正常です。見覚えのない名前があり、かつシェルが/bin/bashのようにログイン可能なものになっていれば要注意です（/usr/sbin/nologinはログインできない設定なので、サービス用として存在していても問題ありません）。

また、管理者権限を持つグループの確認も重要です。

getent group sudo adm

sudo:x:27:kazのように、末尾のメンバー一覧が自分だけかを見ます。

チェック2：SSHの鍵が勝手に追加されていないか

sudo find /home /root -name authorized_keys -exec ls -l {} \; -exec cat {} \;

「全ユーザーのSSH公開鍵ファイルの場所と中身を表示」します。authorized_keysは「この鍵を持っている人はパスワードなしで入れる」という許可リストなので、攻撃者が最初に足がかりとして書き込む場所です。

-rw------- 1 kaz kaz 98 Jul  2 10:20 /home/kaz/.ssh/authorized_keys
ssh-ed25519 AAAAC3Nza... kaz@macbook

行末のコメント（kaz@macbook）が自分の端末名かを確認します。身に覚えのない行があれば、その行だけを削除すれば元に戻せます（ファイル全体を消すと自分も入れなくなるので注意）。編集前にsudo cp authorized_keys authorized_keys.bakでバックアップを取っておけば安全です。

チェック3：見慣れないプロセス・通信がないか

sudo ss -tulpn

「待ち受け中のポートと、それを開いているプログラム名を表示」します。netstatは非推奨となっており、現在はssが標準です。

Netid State  Local Address:Port  Process
tcp   LISTEN 0.0.0.0:22          users:(("sshd",pid=812,fd=3))
tcp   LISTEN 127.0.0.1:5432      users:(("postgres",pid=1104,fd=5))

見るべきは左側のアドレスです。127.0.0.1は「そのサーバー内部からしかアクセスできない」ので安全側、0.0.0.0や*は「インターネットから届く」状態です。自分が動かした覚えのないプログラムが0.0.0.0で待ち受けていたら要調査です。特に、プロセス名が数字の羅列や意味不明な文字列になっているものは危険信号です。

あわせて自動起動の設定も確認します。

systemctl list-unit-files --state=enabled --type=service

OS起動時に自動で動くサービスの一覧です。ssh.service・cron.serviceなど見覚えのある名前ばかりなら正常。インストールした覚えのないサービスが有効化されていれば調べます。crontab -l（自分の定期実行設定）とsudo crontab -l（rootの定期実行設定）も同様に確認しておくとよいでしょう。

侵入の疑いが濃い場合にやること

「失敗の直後にAcceptedが出ている」「知らないユーザーや鍵がある」といった状況なら、次の順で動きます。


ログを先に保全する。sudo journalctl -u ssh --since "30 days ago" > ~/ssh_log_backup.txtで退避します。再インストールすると証拠が消えます
不審な鍵を削除し、全ユーザーのパスワードを変更する（sudo passwd ユーザー名）
侵入が確認できた場合、そのサーバーは作り直すのが原則です。侵入後に何を仕込まれたかを完全に洗い出すのは、経験があっても難しい作業です。VPSならスナップショットから、あるいは新規に立て直してデータだけ移すほうが確実で早いです


なお、ログを追う作業中にサーバーが応答しなくなる、プロセスが強制終了されるといった症状が出る場合は、攻撃ではなくメモリ不足が原因のこともあります。切り分けの参考としてClaude Code Killed メモリ不足解消 26年8月も参考になります。

ログを静かにする設定：鍵認証・fail2ban・ファイアウォール

ここからは設定変更を伴います。特にSSH設定は間違えると自分もログインできなくなるため、手順と戻し方を明示します。

鍵認証に切り替えてパスワード認証を止める（最も効果が大きい）

総当たり攻撃はパスワードを試す攻撃なので、パスワード認証を無効にすれば原理的に成功しません。2026年時点で推奨される鍵の種類はEd25519で、RSA-4096は古いクライアントとの互換性のための選択肢という位置づけです。

手元のPCで鍵を作り、サーバーに登録します。

ssh-keygen -t ed25519 -C "myname@mypc"
ssh-copy-id ユーザー名@サーバーのIP

ここで必ず、いったん別のターミナルを開いて鍵でログインできることを確認してください。確認できたら設定を変更します。

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo nano /etc/ssh/sshd_config

1行目で設定ファイルのバックアップを取っています。次の2行を書き換えます。

PasswordAuthentication no
PermitRootLogin no

そして今のSSH接続はつないだまま、設定を反映します。

sudo sshd -t && sudo systemctl reload ssh

sshd -tは設定ファイルの文法チェックで、エラーがあれば&&の後ろは実行されません。この安全策があるため、書式ミスでサービスが止まる事故は防げます。

戻し方：現在の接続を切らずに、別ターミナルから新規ログインできることを確認します。できなければ、つないだままの接続でsudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config && sudo systemctl reload sshを実行すれば元に戻ります。

fail2banで繰り返す攻撃元を自動遮断する

fail2banはログを監視して、一定回数失敗したIPを一時的に遮断するツールです。鍵認証にしてあれば安全性の上積みは小さいですが、ログのノイズが劇的に減るので点検が楽になります。

sudo apt install fail2ban
sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Ubuntu 24.04以降ではsshd用の設定が初期状態で有効なため、インストールと起動だけで動きます。状態確認の出力はこうなります。

Status for the jail: sshd
|- Filter
|  |- Currently failed: 2
|  `- Total failed:     4821
`- Actions
   |- Currently banned: 5
   `- Total banned:     213

Currently bannedが0より大きければ機能しています。自分のIPを誤って遮断してしまった場合は、サーバーのコンソール（VPS管理画面のWebコンソール等）からsudo fail2ban-client set sshd unbanip 自分のIPで解除できます。丸ごと止めるならsudo systemctl disable --now fail2banです。

ufwで待ち受けポートを絞る

ufwはUbuntu標準のファイアウォール設定ツールです。順番を間違えるとSSHごと遮断されます。必ずこの順で実行してください。

sudo ufw allow OpenSSH
sudo ufw status
sudo ufw enable

SSHを許可してから有効化するのが鉄則です。有効化後は次で確認します。

sudo ufw status verbose

Status: active
Default: deny (incoming), allow (outgoing)
To                         Action      From
OpenSSH                    ALLOW       Anywhere

Default: deny (incoming)で、必要なポートだけがALLOWになっていれば正常です。元に戻すにはsudo ufw disableで、ルールは保持したまま無効化できます。

ポート番号の変更は「本質的な対策ではない」

22番ポートを別の番号に変える対策はよく紹介されますが、2026年時点の評価としては低強度のスキャンを減らしてログをきれいに保つ効果はあるものの、本質的なセキュリティ強化ではないとされています。標的を定めた攻撃者にはポートスキャンで容易に見つけられるためです。やるなら鍵認証と組み合わせる前提で、単独の対策と考えないでください。

より根本的な選択肢として、TailscaleのようなメッシュVPNを使ってSSHをインターネットに公開しない構成があります。公開IPで待ち受けなければ総当たり攻撃を受けること自体がなくなるため、2026年はこの考え方が広まっています。ポート開放が難しい家庭回線でも使えるのが利点です。

OSとカーネルの更新：CVEを1件ずつ追わない現実的な運用

ログイン監視と並んで重要なのが更新です。ただし、LinuxカーネルのCVE（脆弱性の識別番号）公開数は2024年が3,529件、2025年が5,530件と28%増え、1日平均8〜9件のペースになっています。この増加は品質低下ではなく、LinuxカーネルチームがCVE採番機関（CNA）になり、以前は公開されなかった問題まで透明に開示されるようになった結果です。

この件数を1件ずつ精査するのは現実的ではありません。個人や小規模サーバーでは「配布元の更新を素早く当てる」だけで十分です。

sudo apt update && sudo apt upgrade
sudo apt install unattended-upgrades
sudo dpkg-reconfigure --priority=low unattended-upgrades

3行目はセキュリティ更新の自動適用を有効にする対話設定です。カーネル更新後に再起動が必要かは次で確認します。

ls /var/run/reboot-required

ファイルが存在すれば再起動待ち、No such file or directoryなら再起動は不要です。

2026年6月〜8月にも、btrfsのUse-After-Free（CVE-2026-68442、8月13日公開）、DRM/Xe GuCドライバの権限昇格（CVE-2026-68382、8月14日公開）、BluetoothのISO処理（CVE-2026-74535、8月15日公開）などが立て続けに公開されました。8月6日公開のSCTP脆弱性「SCTPhantom」（CVE-2026-64564）は2008年から存在していたもので、修正はstable kernel 7.1.6 / 6.18.42 / 6.12.101 / 6.6.148として8月3日にリリース済みです。いずれもローカル権限昇格が主で、まず外部から入られないこと（＝SSHの守り）が先決という優先順位は変わりません。

なお、こうした脆弱性が自分の環境に該当するかを確認する手順の考え方は、CVE-2026-68820影響確認とKB番号点検【26年8月】で扱った方法とほぼ共通です。

サポート期限も押さえておきましょう。


ディストリビューションリリースサポート期限
Ubuntu 26.04 LTS "Resolute Raccoon"2026年4月23日標準5年（Ubuntu Proで最大10年のESM）
Debian 13 "Trixie"2025年8月9日（13.6が2026年7月11日）全面サポート2028年8月9日 / LTS 2030年6月30日


まとめ：見るべきは失敗の数ではなく「成功の中身」

SSHへの総当たり攻撃はLinuxへの攻撃活動の89%を占め、新しいサーバーが公開IPを取得して数分で始まります。ログに大量の失敗が並ぶこと自体は異常ではありません。判別のポイントは3つです。第一に、journalctl -u ssh | grep "Accepted"で成功したログインを全部確認し、自分の記録だけかを見ること。第二に、lastbで狙われたユーザー名を数え、rootやadminなどの汎用名ばかりなら自動スキャン、実在する固有名なら要警戒と判断すること。第三に、失敗の直後に同じIPからAcceptedが出ていないかを見ることです。対策の優先順位は明快で、鍵認証（Ed25519）への切り替えとパスワード認証の無効化が最も効き、fail2banとufwはログを静かにして点検を楽にする補助、ポート番号変更は本質的対策ではありません。設定を変えるときはsshd_configのバックアップとsshd -tによる文法チェック、そして今の接続を切らずに別ターミナルで入れることを確認する——この3つを守れば、締め出される事故は防げます。