フォローする 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
| ディストロファミリー | ログファイル | ジャーナルコマンド |
|---|---|---|
| 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のように日付が記載されています。インシデントが先週始まった場合、それらも必要です。
これは、現在のファイルとローテートされたファイルから最も古いものを最初に、1つのファイルにsshd行を引き出します：
# 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スタイルの行が得られるので、推測する必要がありません。ジャーナルのすべてのフィールド（PID、ブートID、ホスト名など）を保持したい場合、-o jsonを使用すると、1行あたり1つのJSONオブジェクトが書き込まれます。ファイルは大きくなりますが、何も失われません。
タイムフィルターは、相対的な値も受け入れます：–since “2 hours ago”や–since yesterdayを使用します。持続的ジャーナルで-b -1を使用すると、前回のブートに出力を制限することができます。これはインシデント後にサーバーが再起動された場合に便利です。
バイナリ.journalファイルを/var/log/journalからコピーしてそれらをアップロードしないでください。LogTotalはテキストとJSONを読み、ジャーナルファイルはどちらでもありません。
ファイルを入手したら何を探すべきか
ほとんどのsshd行は、いくつかのパターンに分類されます：
| 行はこれで始まります | それが何を意味するか |
|---|---|
| Failed password for <user> from <ip> | 存在するアカウントへの間違ったパスワード |
| Invalid user <user> from <ip> | ユーザー名は存在しません；スキャナが管理者、テスト、オラクルなどを巡る典型的なもの |
| Accepted password for / Accepted publickey for | 成功したログイン；publickey行はキーの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以降でも、ペナルティについてのメッセージを見ることがあります：sshdは認証に失敗し続けるアドレスを一時的に拒否します。それらを症状として扱ってください。それらはポートを叩いていたことを示しており、誰かが侵入したことを示しているわけではありません。
LogTotalでアップロード、清掃、レビュー
数百行を目視で読むのは良いです。40,000行を読むのはそうではありません。LogTotalは、何も設定せずにログファイルに対して検出ロジックを実行するためのSOC Primeの無料サービスです。アップロードしたものを清掃し、ファイルは保持しません。
- アップロード。 開く logtotal.com にログファイルweb-03_sshd.logをドラッグ＆ドロップします。
- 清掃。 結果を確認してから進みます。それらの名前のうち、どれが自分の環境で機密性があるかを知っています。
- レビュー。
うまくいかないとき
| 症状 | 考えられる原因 | Fix |
|---|---|---|
| auth.logに「ファイルまたはディレクトリが存在しません」というメッセージ | rsyslogがインストールされていません（Debian 12以降のデフォルト） | journalctlを使う、ステップ2b |
| ログファイルに「アクセスが拒否されました」というメッセージ | auth.logはadm専用、secureはroot専用 | sudo、またはアカウントをadmに追加 |
| journalctl -u sshで何も返されず、他のユーザーに関するヒントが表示される | systemd-journal、admまたはwheelにいません | sudo、またはアカウントをsystemd-journalに追加 |
| journalctl -u sshがrootで何も返さない | このディストロに適したユニット名ではありません | -u ssh -u sshdを使用 |
| ログアウトはあるが、Accepted行がない | OpenSSH 9.8+でタグ(-t sshd)でフィルタリングしている | 代わりにユニットでフィルタリング |
| 最後のリブート以前のものが何もない | 一時的ジャーナル；/var/log/journalがない | 古いログはなくなっています；SIEMまたはログフォワーダーを確認 |
| ファイルが数日しかカバーしていない | ローテートされたファイルが含まれていない | auth.log*またはsecure*でzgrepコマンドを使用 |
| タイムスタンプが他のソースと一致しない | クラシックsyslogタイムスタンプにはタイムゾーンがない | サーバーのタイムゾーンを記録する、または-o short-isoでエクスポート |
FAQ
UbuntuではSSHログはどこにありますか？
標準のUbuntuインストールでは、/var/log/auth.logとジャーナル（journalctl -u ssh）にあります。最小のクラウドイメージは時々rsyslogを外してしまいます。ファイルがない場合は、ジャーナルを使用してください。
失敗したSSHログインだけを見るにはどうすればいいですか？
journalシステムでは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のシグマルールがどう解釈するか見てみましょう。すべてのLinuxサーバーで一度にファイルではなく同じ検出ロジックを稼働させたい場合。
参考資料
- Debian 12リリースノート：システムログの変更
- OpenSSH 9.8リリースノート：sshd / sshd-sessionの分割とログタグの変更
- journalctl(1)：ユニットフィルター、出力フォーマット、ジャーナルアクセスグループ
- journald.conf(5)：永続的対一時的なストレージ
