2026年9月、初期設定のままのパスワードを使ったRDP・SSHサーバーを狙うボット型の侵入が増えているという注意喚起が出ています。警察庁が2026年3月に公表した資料でも、ランサムウェア被害の侵入経路の8割超が「外部公開されたリモートアクセス経路」(VPN機器が約62%、リモートデスクトップが約22%)で、パッチ未適用など「基本対策の不備」が原因の中心だとされています。難しい攻撃を防ぐ前に、まず「自分のサーバーに今誰がどこから入っているか」を自分の目で確認する方法を、コマンドの見方まで含めて説明します。
まず過去のログイン履歴をlast・lastb・who・wで洗い出す
いきなり「今の接続」を見る前に、過去にどんなログインがあったかを4つのコマンドで押さえておきます。どれもUbuntu・Debianに標準で入っており、追加インストールは不要です。
コマンド | 何を見ているか | sudo |
|---|---|---|
| ログインに成功した履歴(/var/log/wtmp) | 不要 |
| ログインに失敗した履歴(/var/log/btmp) | 必要 |
| 今ログインしている人の一覧(シンプル版) | 不要 |
| 今ログインしている人＋実行中のコマンド | 不要 |
last -a | head -n 10出力例(ユーザー名・ホスト名・IPは架空のものです):
username pts/0 Mon Sep 21 09:12 still logged in 203.0.113.10
username pts/0 Sun Sep 20 22:03 - 22:40 (00:37) 203.0.113.10
root pts/1 Sun Sep 20 03:14 - 03:15 (00:01) 198.51.100.77ここで見るのは「見覚えのないIPアドレス」「深夜・早朝など普段使わない時間帯」「rootで直接ログインした形跡」の3点です。上の例なら、203.0.113.10は自分がいつも使う回線だとして、198.51.100.77が心当たりのないIPでrootに1分だけログインしていれば要注意です。lastb(失敗履歴)は数十〜数百件並ぶのが普通で、それ自体は自動スキャンによるものが大半なので驚く必要はありません。問題は「失敗の直後に同じIPからの成功がlastに出てくる」場合です。
journalctl -u ssh --since で直近のSSHログを時間指定で追う
Ubuntu/Debianは単位名が「ssh」
SSHのサービス名はディストリで異なります。Ubuntu・Debianはssh.serviceという名前ですが、RHEL・CentOS・Fedora系はsshd.serviceです。名前を間違えると「ログが空」に見えて誤判定するので注意してください。
sudo journalctl -u ssh --since "2 hours ago"これは「直近2時間にSSHサービスが記録した認証ログ」を見ています。一般ユーザーの権限では認証ログが読めないディストリが多いため、基本的にsudoが必要です(設定変更は伴わないので実行しても環境は壊れません)。
出力例:
Sep 21 09:12:03 myserver sshd[10234]: Accepted publickey for username from 203.0.113.10 port 51422 ssh2
Sep 21 04:07:11 myserver sshd[10188]: Failed password for root from 198.51.100.55 port 41220 ssh2
Sep 21 04:07:15 myserver sshd[10190]: Failed password for admin from 198.51.100.55 port 41230 ssh2Acceptedが成功、Failed passwordが失敗です。判断のポイントは以下の3つです。
- Acceptedの行に、身に覚えのないIPが出ていないか
- Failed passwordが同一IPから短時間に連続していないか(ボットの総当たりの典型パターン)
- 存在しないはずのユーザー名(root・admin・test等)宛てのFailedが多発していないか
2026年9月時点のDebian 13.7(2026年9月12日リリース)ではOpenSSHが10.0p1に上がっていますが、ログの出力形式自体は上記の例と変わりません。ログイン試行の傾向自体については、以前CVE-2026-31431点検|userns制限2026年9月でも触れたように、放置されたアカウントが狙われやすい状況が続いています。
ss -tnp state established で「今まさに開いている接続」を確認する
journalctlは過去ログですが、ssコマンドは「今この瞬間に張られている通信」を見ます。旧来のnetstatの後継で、Ubuntu・Debianには標準で入っています。
sudo ss -tnp state establishedそれぞれの意味は次の通りです。
-t：TCP接続のみ表示-n：ホスト名解決をせず数字のIPのまま表示(速度優先・誤解を防ぐ)-p：どのプロセスが使っているかを表示。一般ユーザー権限では自分以外のプロセスの情報が見えないためsudoが必要state established：接続済み(=セッションが張られている)ものだけに絞る
出力例:
State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
ESTAB 0 0 10.0.0.5:22 203.0.113.10:51422 users:(("sshd",pid=10234,fd=4))
ESTAB 0 0 10.0.0.5:22 198.51.100.90:33110 users:(("sshd",pid=20501,fd=4))ローカル側のポートが22(SSHの待ち受けポート)になっている行が「今開いているSSH接続」です。ここに出てくるPeer Address(接続元IP)と、先ほどjournalctlで確認したAcceptedのIPを突き合わせてください。同じIPなら自分が今ログインしている接続と一致するはずです。突き合わせても心当たりのないIPがESTAB(接続中)として残っている場合、それは今まさに誰かが入っている状態なので、最優先で対応します。
異常が見つかったときにやること
ここから先は設定変更・強制切断を伴う操作です。手順を間違えても直せるよう、必ず今のSSH接続とは別に、サーバーのコンソール(物理・VPS管理画面のコンソール等)からもログインできる状態を確保してから作業してください。
- 該当セッションを切断する：
ssで得たpidを使いsudo kill 20501(上の例のpid)。または該当ユーザーごと切るならsudo pkill -KILL -u ユーザー名 - パスワードを変更する：
passwd ユーザー名。rootや管理ユーザーのパスワードは特に見直す - 不審な公開鍵が追加されていないか確認する：
cat ~/.ssh/authorized_keysを開き、自分で登録した覚えのない鍵が無いか確認する。あれば該当行を削除するだけで良く、ファイル全体を消す必要はない - パスワード認証を無効化し鍵認証のみにする(任意・要sudo)：
/etc/ssh/sshd_configを編集する前にsudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bakで必ずバックアップを取り、PasswordAuthentication noに変更後sudo systemctl restart sshで反映する。元に戻す場合はsudo cp /etc/ssh/sshd_config.bak /etc/ssh/sshd_config && sudo systemctl restart ssh
侵入の形跡があった場合、攻撃者はログイン経路そのものより「再侵入用の仕掛け」を残すことが多いため、PAMバックドアPlague点検2026年9月最新とld.so.preload点検|Auto-Color2026/9もあわせて確認しておくと安心です。
関連する選択肢
手元のPCを開いている間しか動かない、という問題を避けるなら、常時起動しているサーバーを借りてそこに置く方法があります。料金はプランによって変わります。
SSDプランが月々698円から使える！さくらのVPS
※ 広告を含みます（A8.net）。リンク経由でお申し込みがあった場合、手数料を受け取ることがあります。
まとめ
SSHへの初期パスワード狙いのボット侵入が2026年9月に注意喚起されている状況では、過去ログのlast・lastb・who・wだけでなく、journalctl -u ssh --sinceで直近の認証ログを、ss -tnp state establishedで今まさに開いている接続を突き合わせることが有効です。どちらも読み取り専用のコマンドで、実行するだけでは環境を一切変更しません。異常が見つかったときだけ、バックアップを取ったうえで対処に進んでください。