SSHログとauthorized_keys突合2026年8月版

「Accepted publickey」のログが残っていれば安心、と思っていないだろうか。実は正規ログインと侵入直後の鍵追加は、ログの見た目がよく似ている。本記事ではjournalctl -u ssh(d)の「Accepted publickey」の行とauthorized_keysの更新時刻を突き合わせる具体的な手順と、その方法だけで侵入を見分けられるのか、限界も含めて解説する。Ubuntu/Debian環境で今すぐ手を動かして確認できる粒度でまとめた。

journalctl -u ssh(d)でログイン記録を洗い出す

まず、誰が・いつ・どのIPから公開鍵認証でログインしたかを見る。このコマンドはsshdデーモンが出力したログをsystemdのジャーナル（ログの保管庫）から抽出しているだけで、設定変更は一切発生しない。

実行するコマンド

sudo journalctl -u ssh --no-pager | grep "Accepted publickey"

Ubuntu/Debianではサービス名がsshだが、RHEL・CentOS・Fedora・Arch系ではsshdになる。ユニット名が分からない場合は先に次で確認する。

systemctl list-units --type=service | grep -i ssh

journalctlはログ閲覧用のコマンドで、-u sshで「sshというサービスのログだけ」に絞り込んでいる。一般ユーザーでもadmまたはsystemd-journalグループに入っていれば実行できるが、多くの環境では素直にsudoを付ければよい。設定ファイルは触らないので、実行して壊れるものは何もない。

出力例と見るべき場所

Aug 20 09:00:41 mysrv sshd[10231]: Accepted publickey for kaz from 203.0.113.5 port 51234 ssh2: RSA SHA256:AbCdEf1234...
Aug 27 03:12:07 mysrv sshd[28810]: Accepted publickey for kaz from 198.51.100.9 port 44210 ssh2: ED25519 SHA256:ZzYy9988...

見るのは3点だけ。時刻（自分や関係者が実際に作業していた時間帯か）、送信元IP（見覚えのある回線か。海外や心当たりのないIPは要注意）、鍵の種類とフィンガープリント（同じSHA256:...が普段の端末と一致するか）。2件目のように深夜3時・見慣れないIP・見慣れないフィンガープリントが揃った行は、この時点で「保留」にして次の工程に進む。

authorized_keysの更新時刻を確認する

公開鍵認証でログインできるのは、サーバー側の~/.ssh/authorized_keysに該当する公開鍵が登録されているからだ。ここが「いつ」書き換わったかを見る。

実行するコマンド

find /home -maxdepth 3 -name authorized_keys -exec stat -c '%y %n' {} \;

findで全ユーザーのauthorized_keysを探し、statでファイルの最終更新時刻（mtime）を表示している。自分のホームディレクトリだけならsudo不要だが、他ユーザー分も見る場合はホームディレクトリのパーミッション次第でsudoが必要になる。これも読み取りだけで設定変更は起きない。

出力例

2026-08-15 21:03:12.000000000 +0900 /home/kaz/.ssh/authorized_keys
2026-08-27 03:11:52.000000000 +0900 /home/deploy/.ssh/authorized_keys

deployユーザーのauthorized_keysが、先ほどログで見た「深夜3時・見覚えのないIP」からのログイン（03:12:07）のわずか15秒前に更新されている。ファイルを書き換えた直後にその鍵でログインしている、という並びだ。一方kazの方は8/15に更新されて以降ずっと動いていないので、こちらは普段の運用の範囲内と判断してよい。

タイムスタンプ照合だけで侵入直後の鍵追加を見分けられるか

ここが本題である。結論から言うと、「更新直後にログインしている」という並びは強い手がかりにはなるが、それだけで断定はできない。理由は2つある。

理由1：mtimeは「最後に書き換わった時刻」しか残らない

正規の管理者が新しい端末用に鍵を追記した場合も、見た目はまったく同じ「更新直後にログイン」になる。単発の突き合わせでは、追記したのが本人か侵入者かを区別できない。誰が書き込んだ操作をしたかまで見たい場合は、auditdを導入してauthorized_keysをwatch対象にするのが確実だが、これは新たにパッケージを入れる設定変更になるため、本記事の範囲を超える。まずは前項の「時刻・IP・フィンガープリント」の3点セットで違和感を拾うところから始めるのが現実的だ。

理由2：mtimeは上書きされ、履歴が残らない

侵入者が鍵を追加した後、正規の管理者が別の鍵を追記すると、mtimeは新しい方の時刻に上書きされ、侵入者が追加した痕跡そのものが見えなくなる。1回きりの確認では過去の不正な追記を見落とすということだ。対策として、authorized_keysのハッシュ値を定期的に記録しておくと変化を追跡できる。

sha256sum /home/*/.ssh/authorized_keys >> ~/authorized_keys_history.log

これをcronやsystemd timerで1日1回実行し追記していけば、後から「いつ内容が変わったか」を遡って特定できる。timerの設定状況の点検方法はsystemctl list-timers点検2026年8月版で扱っているので、あわせて確認するとよい。

フィンガープリントで鍵そのものを照合する

ssh-keygen -lf /home/deploy/.ssh/authorized_keys

登録されている鍵のフィンガープリント一覧が出るので、社内の端末台帳やパスワードマネージャーに控えてある「自分が発行した鍵」の一覧と突き合わせる。1行でも心当たりのないフィンガープリントがあれば、それは即座に不正な鍵として扱ってよい。

異常が見つかったときの対処

見覚えのない鍵・見覚えのないIPからのログインが確認できた場合、次の順で対応する。

1. 該当行をauthorized_keysから削除する前に必ずバックアップを取る：cp authorized_keys authorized_keys.bak.$(date +%F)
2. 不正な鍵の行だけをエディタで削除する（sshdの再起動は不要。次回接続時から即座に無効になる）
3. last -FでそのIPからの他のログイン痕跡がないか、パスワードログインも含めて確認する
4. 該当IPを恒常的に遮断するなら、UFWのルールが実際に効いているかUFWとiptables突き合わせで設定漏れ確認2026の手順で確認する
5. rootや他ユーザーへの権限昇格の跡がないかも合わせて見ておく。IPAは2026年8月にLinuxカーネルの権限昇格の脆弱性「CVE-2026-53362（Frag Gap）」がCISAの既知悪用カタログに追加されたと注意喚起しており、鍵の不正利用だけで済んでいない可能性も念頭に置く

誤って正規の鍵を消してしまった場合は、手順1で取ったバックアップから該当行を戻せば復旧できる。設定ファイル（sshd_config）自体には触れていないので、SSH接続そのものが不能になる心配はない。

前提として押さえておきたい環境差

手元のバージョンはssh -Vで確認できる。ディストリのパッケージは上流の最新版より遅れて追随することが多いため、バージョン番号だけで安全と判断せず、本記事のようなログ側の点検も併用するのが実務的だ。なお、Debian 11(bullseye)は2026年8月31日でLTSサポートが終了するため、該当環境が残っている場合は本記事の点検と合わせて更新計画を確認しておきたい。

まとめ

journalctl -u ssh(d)の「Accepted publickey」とauthorized_keysのmtimeを突き合わせる方法は、深夜の時間帯・見慣れないIP・更新直後のログインという組み合わせを拾える点で有効だが、mtimeは最後の書き換えしか記録せず「誰が書いたか」「過去に何度書き換わったか」は分からないという限界がある。日々のハッシュ記録やフィンガープリント台帳との照合を組み合わせることで、単発のタイムスタンプ照合だけでは見えない変化も追跡できるようになる。まずは自分のサーバーで一度コマンドを実行し、見慣れた鍵とIPだけが並んでいるかを確認するところから始めてほしい。