フォローする Debian と Ubuntu では、sshd は /var/log/auth.log に書き込みます。RHEL、Rocky、Alma、CentOS Stream では、/var/log/secure に書き込みます。どちらのファイルも存在しない場合、システムは systemd ジャーナルにのみログを記録します。その際、Debian ベースのシステムでは journalctl -u ssh または、Red Hat ファミリー、Fedora、Arch では journalctl -u sshd が必要です。
SSH はほぼすべての Linux サーバーの玄関口であるため、そのログはほぼすべての Linux 調査で表示されます。Prime Core は、このような Linux 認証ログで動作する 11,632 のシグマ規則を持ち、643 MITRE ATT&CK の技術にマップされています。その中には、ブルートフォース (T1110)、盗まれた資格情報を使用してのログイン (T1078)、SSH を介したラテラルムーブメント (T1021.004) があります。以下に、sshd ログを見つけ、それをエクスポート、正規化し、LogTotal で無料で調査する方法を示します。
TL;DR
| Distro ファミリー | ログファイル | ジャーナルコマンド |
|---|---|---|
| Debian、Ubuntu | /var/log/auth.log | journalctl -u ssh |
| RHEL、Rocky、Alma、CentOS Stream | /var/log/secure | journalctl -u sshd |
| Fedora、Arch、rsyslog を含まない最小インストール | デフォルトではなし | journalctl -u sshd |
開始前に: 本当にそれらを読めますか？
認証ログは意図的にロックダウンされているので、通常のアカウントでは何も返されません。
- Debian と Ubuntu の /var/log/auth.log は root および adm グループによって読み取ることができます。
- Red Hat ファミリーの /var/log/secure は root のみです。
- システムジャーナルは root と systemd-journal、adm、wheel のメンバーに公開されています。他のすべてのユーザーは自分のユーザージャーナルしか見られません。通常ユーザーとして journalctl -u ssh を実行すると、空の結果と他のユーザーからのメッセージが表示されないというヒントが得られます。それは権限の問題であり、静かなサーバーではありません。
簡単な解決策は sudo です。ログ収集専用のアカウントを設定する場合は、root を渡す代わりにそれを adm または systemd-journal に追加します。詳細は弊社の [Linux ログの権限ガイド] で取り上げています。
サーバーから何かをコピーする前にもう一つのこと: 認証ログにはユーザー名、ソース IP、ホスト名が含まれています。LogTotal はアップロードを正規化しますが、まずデータ処理ポリシーを確認してください。
ステップ 1: ファイルかジャーナルか、またはその両方か？
上記の表はデフォルトを示していますが、デフォルトはクラウドイメージやハーデニングスクリプトが変更を好むものです。10 秒かけて確認してください:
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog
ファイルが表示され、rsyslog がアクティブである場合、両方があります: rsyslog はジャーナルからプレーンテキストファイルにメッセージをコピーします。どちらのソースでも機能し、ファイルはコピーしやすいです。
ファイルがない場合、rsyslog は単にインストールされていません。それが今の標準です: Debian 12 以降、rsyslog はデフォルトインストールの一部ではないため、新しい Debian ボックスには auth.log がありません。Fedora と Arch は何年もこの方法で動作しています。ステップ 2b に進みます。
ここにいる間、ジャーナルが再起動後に生き残るかどうか確認します:
ls -d /var/log/journal
そのディレクトリが存在しない場合、journald は /run/log/journal 下にメモリにログを保持し、再起動でそれらを消去します。調査中のマシンでは、誰かが「再起動してみるだけ」と決める前にそれを知っておく価値があります。
インシデントワークのためのもう一つのポイント: ボックスが侵害されている可能性がある場合、そのローカルログもそうかもしれません。auth.log を消去または編集することは古典的なクリーンアップステップです。サーバーがログを SIEM に転送する場合、そこからもエクスポートし、比較してください。弊社の [Splunk エクスポートガイド] はその方法を示しています。
ステップ 2a: auth.log または secure からエクスポートする
現在のファイルは過去数日分のみをカバーしています。古いエントリーはその隣の回転したファイルにあります。Debian と Ubuntu では auth.log.1、auth.log.2.gz などのように見えます。Red Hat ファミリーでは、secure-20261012 のように日付が付けられています。インシデントが先週始まった場合、それも必要です。
これにより、現在と回転したファイルからの sshd ラインが、最古のものから1つのファイルにまとめられます:
# Debian / Ubuntu
sudo zgrep -h ‘sshd’ $(ls -tr /var/log/auth.log*) > web-03_sshd.log
# RHEL / Rocky / Alma
sudo zgrep -h ‘sshd’ $(ls -tr /var/log/secure*) > web-03_sshd.log
zgrep はプレーンファイルと gzip 圧縮ファイルを同様に読み取るため、何も解凍する必要はありません。ls -tr は変更時間で並べ替えるため、最古のファイルが最初に来て、出力は大まかに時系列に整います。sshd パターンはまた sshd-session を一致させ、これは新しいシステムでは重要です（ステップ 2b を参照）。
なぜフィルタリングが必要なのか？ ノイズを削減することに加えて、auth.log は sudo も記録し、sudo ラインは完全なコマンドラインを含んでいます。時折、人々はそこにパスワードを打ち込みます。sshd にフィルターをかけることで、それをファイルから排除します。例外は、攻撃者がログインした後に何をしたかを調査しているときです。 後 その場合は、sudo ラインも必要です: ファイル全体を取り出し、LogTotal の正規化ステップに任せてください。
アップロードする前の簡単なチェック:
wc -l web-03_sshd.log
head -3 web-03_sshd.log; tail -3 web-03_sshd.log
タイムスタンプを見てください。rsyslog の設定によって、従来の syslog (Oct 19 10:15:01、年なし、タイムゾーンなし) または完全な ISO 8601 のいずれかになる可能性があります。従来の形式の場合、サーバーのタイムゾーン (timedatectl) を書き留めてください。それはこれらのイベントを他のものと並べて識別する瞬間に必要です。
ステップ 2b: systemd ジャーナルからエクスポート
ジャーナル専用のシステムでは、これは全作業です:
sudo journalctl -u ssh -u sshd
–since “2026-10-19 00:00” –until “2026-10-20 00:00”
–no-pager -o short-iso > web-03_sshd.log
そこにはいくつかの選択肢があります。
両方のユニット名。 サービスは Debian と Ubuntu では ssh と呼ばれ、ほぼ他の場所では sshd と呼ばれています。journalctl は -u フラグを OR で組み合わせるので、同じコマンドが両方のファミリーで機能します。
ユニットでフィルタリングし、タグではフィルタリングしません。 多くの古いガイドは journalctl -t sshd を使用します。OpenSSH 9.8 以降、サーバーは 2 つのバイナリに分割され、接続ごとのメッセージ（ログインを含む）は sshd ではなく sshd-session としてタグ付けされます。タグでフィルタリングすると、探していたまさにその行を失います。これは 2024 年に 9.8 が上陸したときに、多くの fail2ban や sshguard 設定を破壊しました。RHEL 10 およびその他の現在のリリースは OpenSSH 9.8 以上を出荷します。ユニットでフィルタリングすると、サービスに属するすべてのプロセスがキャッチされます。
-o short-iso. これにより、年とタイムゾーンが含まれた完全な ISO 8601 タイムスタンプで、syslog スタイルの行が得られるため、推測する必要がありません。[証拠: LogTotal が short-iso を解析することを確認します。解析しない場合は、デフォルトの -o short を使用します。] ジャーナルのすべてのフィールド（PID、ブート ID、ホスト名など）を保持する場合は、-o json を使用します。これにより、1 行ごとに 1 つの JSON オブジェクトが記述されます。ファイルは大きくなりますが、何も失われません。
時間フィルターは相対値も受け入れます: –since “2 時間前” または –since yesterday です。持続的なジャーナルでは、-b -1 が出力を前回のブートに制限します。これは、インシデント後にサーバーが再起動された場合に役立ちます。
バイナリ .journal ファイルを /var/log/journal からコピーしてアップロードしないでください。LogTotal はテキストと JSON を読み取り、ジャーナルファイルはどちらでもありません。
ファイルが得られたら何を探すか
ほとんどの sshd ラインは、以下のいくつかのパターンに分類されます:
| 行の先頭 | その意味 |
|---|---|
| Failed password for <user> from <ip> | 既存のアカウントに対する間違ったパスワード |
| Invalid user <user> from <ip> | ユーザー名が存在しません。スキャナーが admin、test、oracle などを巡回する典型的な事例です。 |
| Accepted password for / Accepted publickey for | 成功したログイン。公的鍵の行はまた鍵の SHA256 フィンガープリントを持ちます。 |
| Disconnecting authenticating user … Too many authentication failures | クライアントは MaxAuthTries に達しました |
| Connection closed by <ip> … [preauth] | 認証前にドロップされました。通常はスキャナーとバナーグラバーです。 |
| pam_unix(sshd:session): session opened for user | セッションが実際に開始されました |
停止する価値のあるシーケンス: 1 つの IP からの Failed または Invalid user のラインが続き、同じ IP からの Accepted。これは成功したブルートフォース攻撃です。次にくるもの: 誰も認識しないアドレスからの、誰も働かない時間帯のサービスアカウントへの Accepted。
OpenSSH 9.8 以降では認証に失敗し続けるアドレスを一時的に拒否するペナルティに関するメッセージが表示されることもあります。それらを症状として扱ってください。これは誰かがポートをハンマーしていたことを示し、誰かが侵入したことを示すものではありません。
LogTotal にアップロード、正規化、レビュー
数百行を目で読むのは問題ありませんが、40,000 行はそうではありません。LogTotal は、検出ロジックをログファイルに対して何も設定せずに実行するためのSOC Prime の無料サービスです。アップロードする内容を正規化し、ファイルを保持しません。
- アップロード。 を開く logtotal.com にウィンドウを開き、web-03_sshd.log をドロップしてください。[証拠: アップロード画面、サイズ制限]
- 正規化。 [PROOF: what gets masked in an sshd log: usernames, source IPs, hostnames]. Look over the result before you go on. You know which of those names are sensitive in your environment.
- レビュー。 [PROOF: what the results screen shows and how findings map to rules and ATT&CK techniques]
実際のデータでこれがどのように見えるか。 迷惑メール送信用のテスト VM 上で sshd ログを生成しました: [証拠: SSH パスワードスプレー攻撃のシミュレーション、数多くの一般的なユーザー名を試した後、成功したログインに終わりました]。ファイルは [証拠: N 行、X KB] 出力されました。LogTotal は [証拠: 実際の発見、適合した規則、ATT&CK 技術] をフラグしました。
自分のサーバーを触る前に試したいですか？ [証拠: サンプルファイルへのリンク] は、上記で使用したファイルと同一です。
問題が発生した際
| 症状 | 考えられる原因 | Fix |
|---|---|---|
| auth.log に No such file or directory | rsyslog がインストールされていません（Debian 12 以降のデフォルト） | journalctl を使用、ステップ 2b |
| ログファイルでの Permission denied | auth.log は adm のみ、secure は root のみ | sudo を使用、またはアカウントを adm に追加 |
| journalctl -u ssh で何も返されない、他のユーザーについてのヒント | あなたは systemd-journal、adm または wheel にはいません | sudo を使用、またはアカウントを systemd-journal に追加 |
| root でも journalctl -u ssh で何も返されない | このディストリのユニット名が間違っています | -u ssh -u sshd を使用 |
| ログアウトはあるが、Accepted ラインがない | OpenSSH 9.8+ でのタグ (-t sshd) によるフィルタリング | ユニットでフィルタリング |
| 最後の再起動より古いものがない | 揮発性ジャーナル; /var/log/journal がない | 古いログはなくなりました。SIEM またはログ転送者を確認してください。 |
| ファイルが数日分しかカバーしていない | 回転したファイルが含まれていない | zgrep コマンドを auth.log* または secure* で使用 |
| タイムスタンプが他のソースと一致しない | 古典的な syslog タイムスタンプにはタイムゾーンがありません | サーバーのタイムゾーンをメモするか、-o short-iso でエクスポートしてください |
FAQ
Ubuntu での SSH ログの場所は？
標準の Ubuntu インストールでは、/var/log/auth.log にあり、ジャーナル（journalctl -u ssh）もあります。ミニマルなクラウドイメージでは rsyslog が省かれることもあります。ファイルがない場合、ジャーナルを使用してください。
失敗した SSH ログインのみを表示する方法は？
ジャーナルシステムでは sudo journalctl -u ssh -u sshd | grep -E ‘Failed|Invalid user’ を、ファイルがある場合は sudo zgrep -hE ‘Failed|Invalid user’ /var/log/auth.log* で行います。ざっと見るためのものでない限り、sshd の全ログをアップロードしてください。失敗は成功の次に現れることで意味を持ちます。
last と lastb はどう？
これらは /var/log/wtmp および /var/log/btmp にあるバイナリログイン記録を読み取ります。誰がログインしたかを素早く見るのには便利ですが、sshd 自体のログより詳細は持ちませんし、侵入者が簡単に改ざんできます。
複数のサーバから sshd ログを一度に収集する方法は？
一度限りの場合、ループで行います: for h in web-01 web-02 web-03; do ssh “$h” “sudo journalctl -u ssh -u sshd –since yesterday -o short-iso –no-pager” > “${h}_sshd.log” done これは、リモート側でパスワード要求なしで動作するために sudo を必要とします。そうでない場合、ssh に -t を追加し、パスワードを毎回入力してください。四半期に 1 回以上行うなら、ログを SIEM に送るべきです。
sshd ログをオンラインツールにアップロードしても安全ですか？
LogTotal はアップロード後に分析し正規化し、ファイルを保持しません。我々の[正規化ガイド] は何が隠されるかを示しています。あなたの組織のデータ処理ルールが最優先です。
次のステップ
ファイルを取得しましたか？ LogTotal にアップロード して、11,632 のシグマルールがそれをどう評価するか見てください。同じ検出ロジックを 1 つのファイルごとではなく、すべての Linux サーバーで実行したい場合。
参考
- Debian 12 リリースノート: システムログの変更
- OpenSSH 9.8 リリースノート: sshd / sshd-session の分割と変更されたログタグ
- journalctl(1): ユニットフィルター、出力形式、ジャーナルアクセスグループ
- journald.conf(5): 永続対揮発性ストレージ
