Folgen Auf Debian und Ubuntu schreibt sshd in /var/log/auth.log. Auf RHEL, Rocky, Alma und CentOS Stream schreibt es in /var/log/secure. Wenn keine dieser Dateien existiert, protokolliert Ihr System nur in das systemd-Journal. Dann lautet der Befehl, den Sie möchten: journalctl -u ssh auf Debian-basierten Systemen oder journalctl -u sshd auf der Red Hat-Familie, Fedora und Arch.
SSH ist die Eingangstür fast jedes Linux-Servers, weshalb seine Protokolle in fast jeder Linux-Untersuchung auftauchen. Prime Core hat 11.632 Sigma-Regeln, die auf Linux-Authentifikationsprotokollen wie diesen laufen, abgebildet auf 643 MITRE ATT&CK-Techniken. Darunter: Brute Force (T1110), Anmeldungen mit gestohlenen Anmeldedaten (T1078) und laterale Bewegung über SSH (T1021.004). Im Folgenden erfahren Sie, wie Sie Ihre sshd-Protokolle finden, exportieren, bereinigen und kostenlos in LogTotal untersuchen können.
Zusammenfassung
| Distro-Familie | Protokolldatei | Journal-Befehl |
|---|---|---|
| Debian, Ubuntu | /var/log/auth.log | journalctl -u ssh |
| RHEL, Rocky, Alma, CentOS Stream | /var/log/secure | journalctl -u sshd |
| Fedora, Arch, Minimalinstallationen ohne rsyslog | standardmäßig keine | journalctl -u sshd |
Bevor Sie beginnen: Können Sie sie tatsächlich lesen?
Authentifizierungsprotokolle sind absichtlich gesperrt, sodass ein normales Konto in der Regel nichts zurückerhält.
- /var/log/auth.log auf Debian und Ubuntu ist für root und die adm-Gruppe lesbar.
- /var/log/secure in der Red Hat-Familie ist nur für root.
- Das Systemjournal ist für root und Mitglieder von systemd-journal, adm und wheel offen. Alle anderen sehen nur ihr eigenes Benutzerjournal. Wenn Sie journalctl -u ssh als normaler Benutzer ausführen, erhalten Sie ein leeres Ergebnis und einen Hinweis darauf, dass Sie keine Nachrichten von anderen Benutzern sehen. Das liegt an den Berechtigungen, nicht an einem ruhigen Server.
Die einfache Lösung ist sudo. Wenn Sie ein Konto nur zur Protokollsammlung einrichten, fügen Sie es adm oder systemd-journal hinzu, anstatt root zu vergeben. Unser [Linux-Protokollberechtigungshandbuch] enthält die Details.
Eine weitere Sache, bevor Sie etwas von einem Server kopieren: Auth-Protokolle enthalten Benutzernamen, Quell-IP-Adressen und Hostnamen. LogTotal bereinigt Uploads, aber prüfen Sie zuerst Ihre Datenverarbeitungsrichtlinie.
Schritt 1: Datei, Journal oder beides?
Die Tabelle oben zeigt die Standards, und genau diese ändern Images aus der Cloud und Hardening-Skripte gerne. Verbringe zehn Sekunden zum Überprüfen:
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog
Wenn eine Datei angezeigt wird und rsyslog aktiv ist, haben Sie beides: rsyslog kopiert Nachrichten aus dem Journal in eine reine Textdatei. Jede Quelle funktioniert, und die Datei ist leichter zu kopieren.
Wenn keine Datei vorhanden ist, ist rsyslog einfach nicht installiert. Das ist jetzt der Standard: Seit Debian 12 ist rsyslog nicht mehr Teil einer Standardinstallation, sodass eine neue Debian-Box kein auth.log hat. Fedora und Arch arbeiten auf diese Weise schon seit Jahren. Gehen Sie zu Schritt 2b.
Während Sie hier sind, prüfen Sie, ob das Journal einen Neustart überlebt:
ls -d /var/log/journal
Wenn dieses Verzeichnis nicht existiert, hält journald Protokolle im Speicher unter /run/log/journal, und ein Neustart löscht sie. Auf einem Rechner, den Sie untersuchen, ist das wissenswert, bevor jemand entscheidet, „einfach neu zu starten.“
Ein weiterer Punkt für Vorfallarbeiten: Wenn die Box möglicherweise kompromittiert ist, können auch ihre lokalen Protokolle betroffen sein. Das Löschen oder Bearbeiten von auth.log ist ein klassischer Reinigungsschritt. Wenn der Server Protokolle an ein SIEM weiterleitet, exportieren Sie auch von dort und vergleichen Sie. Unser [Splunk-Exporthandbuch] zeigt, wie.
Schritt 2a: Exportieren von auth.log oder secure
Die aktuelle Datei deckt nur die letzten Tage ab. Ältere Einträge befinden sich in rotierenden Dateien daneben. Auf Debian und Ubuntu sehen sie aus wie auth.log.1, auth.log.2.gz und so weiter. In der Red Hat-Familie tragen sie ein Datum, wie secure-20261012. Wenn der Vorfall letzte Woche begann, benötigen Sie diese ebenfalls.
Dies zieht sshd-Zeilen aus der aktuellen und rotierenden Dateien, älteste zuerst, in eine Datei:
# 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 liest sowohl normale als auch komprimierte Dateien, sodass Sie nichts entpacken müssen. ls -tr sortiert nach Änderungszeit, sodass die älteste Datei zuerst kommt und die Ausgabe ungefähr chronologisch bleibt. Das Muster „sshd“ entspricht auch sshd-session, was auf neueren Systemen wichtig ist (siehe Schritt 2b).
Warum überhaupt filtern? Neben dem Reduzieren von Lärm zeichnet auth.log auch sudo auf, und sudo-Zeilen enthalten vollständige Befehlszeilen. Menschen geben gelegentlich Passwörter in diese ein. Filtern auf sshd hält das aus der Datei heraus. Die Ausnahme ist, wenn Sie untersuchen, was ein Angreifer getan hat nachdem er sich angemeldet hat. Dann möchten Sie auch die sudo-Zeilen: Nehmen Sie die ganze Datei und lassen Sie LogTotal den Bereinigungsschritt erledigen.
Schnellüberprüfung vor dem Hochladen:
wc -l web-03_sshd.log
head -3 web-03_sshd.log; tail -3 web-03_sshd.log
Schauen Sie sich die Zeitstempel an. Abhängig von der rsyslog-Konfiguration sind sie entweder klassisches Syslog (19. Okt 10:15:01, kein Jahr, keine Zeitzone) oder vollständiges ISO 8601. Wenn sie klassisch sind, schreiben Sie die Zeitzone des Servers (timedatectl) auf. Sie benötigen sie sofort, wenn Sie versuchen, diese Ereignisse mit anderen in Einklang zu bringen.
Schritt 2b: Exportieren aus dem systemd-Journal
Auf systemgebundenen Systemen ist dies der gesamte Job:
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
Einige Entscheidungen darin sind bewusst gewählt.
Beide Einheitsnamen. Der Dienst wird auf Debian und Ubuntu ssh genannt und fast überall sonst sshd. journalctl kombiniert wiederholte -u-Flags mit ODER, sodass der gleiche Befehl auf beiden Familien funktioniert.
Nach Einheit und nicht nach Tag filtern. Viele ältere Leitfäden verwenden journalctl -t sshd. Seit OpenSSH 9.8 ist der Server in zwei Binärdateien gesplittet, und Verbindungsnachrichten, einschließlich Anmeldungen, sind mit sshd-session anstelle von sshd gekennzeichnet. Wenn Sie nach Tag filtern, verlieren Sie genau die Zeilen, die Sie suchen. Dies hat viele fail2ban und sshguard Setups gebrochen, als 9.8 2024 eingeführt wurde. RHEL 10 und andere aktuelle Versionen enthalten OpenSSH 9.8 oder neuer. Das Filtern nach Einheit erfasst jeden Prozess, der zum Dienst gehört, wie auch immer er genannt wird.
-o short-iso. Es gibt Ihnen eine Syslog-ähnliche Zeile mit einem vollständigen ISO 8601-Zeitstempel, Jahr und Zeitzone inklusive, sodass Sie nicht raten müssen. Wenn Sie lieber jedes Journalfeld behalten möchten (PID, Boot-ID, Hostname usw.), verwenden Sie -o json, das ein JSON-Objekt pro Zeile schreibt. Die Datei wird größer, aber nichts geht verloren.
Die Zeitfilter nehmen auch relative Werte: –since „vor 2 Stunden“ oder –seit gestern. Mit einem dauerhaften Journal begrenzt -b -1 die Ausgabe auf den vorherigen Boot, was hilft, wenn der Server nach dem Vorfall neu gestartet wurde.
Kopieren Sie nicht die binären .journal-Dateien aus /var/log/journal und laden Sie diese hoch. LogTotal liest Text und JSON, und Journal-Dateien sind weder noch.
Worauf Sie achten sollten, sobald Sie die Datei haben
Die meisten sshd-Zeilen fallen in eine Handvoll Muster:
| Zeile beginnt mit | Was es bedeutet |
|---|---|
| Fehlgeschlagenes Passwort für <user> von <ip> | Falsches Passwort für ein vorhandenes Konto |
| Ungültiger Benutzer <user> von <ip> | Der Benutzername existiert nicht; typisch für Scanner, die Admin, Test, Oracle durchlaufen |
| Akzeptiertes Passwort für / Akzeptierter öffentlicher Schlüssel für | Eine erfolgreiche Anmeldung; die Zeile mit öffentlichem Schlüssel enthält auch den SHA256-Fingerabdruck des Schlüssels |
| Authentifizierenden Benutzer trennen … Zu viele Authentifizierungsfehler | Der Client hat MaxAuthTries erreicht |
| Verbindung von <ip> geschlossen … [preauth] | Vor der Authentifizierung abgelehnt, normalerweise Scanner und Bannergrabber |
| pam_unix(sshd:session): Sitzung für Benutzer geöffnet | Die Sitzung hat tatsächlich begonnen |
Die Sequenz, bei der es sich lohnt, sie zu stoppen: eine Reihe von fehlgeschlagenen oder ungültigen Benutzerzeilen von einer IP, dann ein akzeptiertes von derselben IP. Das ist ein erfolgreicher Brute-Force-Angriff. Dicht gefolgt von einem akzeptierten Servicekonto, von einer Adresse, die niemand erkennt, zu einer Stunde, in der niemand arbeitet.
Bei OpenSSH 9.8 und später können Sie auch Nachrichten über Strafen sehen: sshd verweigert nun vorübergehend Adressen, die die Authentifizierung ständig fehlschlagen. Behandeln Sie sie als Symptom. Sie sagen Ihnen, dass jemand den Port gehämmert hat, nicht dass jemand eingedrungen ist.
Hochladen, bereinigen und in LogTotal überprüfen
Ein paar hundert Zeilen mit den Augen zu lesen, ist in Ordnung. 40.000 zu lesen ist das nicht. LogTotal ist der kostenlose Dienst von SOC Prime, um Erkennungslogik gegen eine Protokolldatei laufen zu lassen, ohne irgendetwas einzurichten. Es bereinigt, was Sie hochladen, und behält Ihre Dateien nicht.
- Hochladen. Gehen Sie zu logtotal.com und ziehen Sie die Datei web-03_sshd.log hinein.
- Bereinigen. Schauen Sie sich das Ergebnis an, bevor Sie weitermachen. Sie wissen, welche dieser Namen in Ihrer Umgebung sensibel sind.
- Überprüfen.
Wenn es schiefgeht
| Symptom | Wahrscheinliche Ursache | Fix |
|---|---|---|
| Keine solche Datei oder Verzeichnis für auth.log | rsyslog ist nicht installiert (Standard seit Debian 12) | Verwenden Sie journalctl, Schritt 2b |
| Zugriff verweigert auf die Protokolldatei | auth.log ist nur für adm, secure ist nur für root | sudo, oder fügen Sie das Konto zu adm hinzu |
| journalctl -u ssh gibt nichts zurück, mit einem Hinweis auf andere Benutzer | Sie sind nicht in systemd-journal, adm oder wheel | sudo, oder fügen Sie das Konto zu systemd-journal hinzu |
| journalctl -u ssh gibt nichts zurück als root | Falscher Einheitsname für diese Distro | Verwende -u ssh -u sshd |
| Abmeldungen sind da, aber keine akzeptierten Zeilen | Filtern nach Tag (-t sshd) auf OpenSSH 9.8+ | Filtern Sie stattdessen nach Einheit |
| Nichts älter als der letzte Neustart | Flüchtiges Journal; kein /var/log/journal | Die alten Protokolle sind weg; prüfen Sie Ihr SIEM oder Protokollweiterleiter |
| Die Datei umfasst nur wenige Tage | Rotierte Dateien wurden nicht einbezogen | Verwenden Sie den zgrep-Befehl mit auth.log* oder secure* |
| Zeitstempel stimmen nicht mit anderen Quellen überein | Klassische Syslog-Zeitstempel tragen keine Zeitzone | Notieren Sie die Zeitzone des Servers oder exportieren Sie mit -o short-iso |
FAQ
Wo sind SSH-Protokolle auf Ubuntu?
Auf einer Standard-Ubuntu-Installation in /var/log/auth.log, sowie im Journal (journalctl -u ssh). Minimale Cloud-Images lassen rsyslog manchmal weg. Wenn die Datei nicht vorhanden ist, verwenden Sie das Journal.
Wie sehe ich nur fehlgeschlagene SSH-Anmeldungen?
sudo journalctl -u ssh -u sshd | grep -E ‚Failed|Invalid user‘ auf Journalsystemen, oder sudo zgrep -hE ‚Failed|Invalid user‘ /var/log/auth.log* wenn Sie die Datei haben. Für alles über einen kurzen Blick hinaus, laden Sie das vollständige sshd-Protokoll stattdessen hoch. Die Fehler haben nur Bedeutung neben den Erfolgen.
Was ist mit last und lastb?
Diese lesen die binären Anmeldeaufzeichnungen in /var/log/wtmp und /var/log/btmp. Sie sind nützlich für einen schnellen Blick darauf, wer sich angemeldet hat, tragen jedoch weit weniger Details als das eigene Protokoll von sshd, und sie sind genauso leicht zu manipulieren für einen Eindringling.
Wie sammle ich sshd-Protokolle gleichzeitig von mehreren Servern?
Für einmalig erledigt eine Schleife das: for h in web-01 web-02 web-03; do ssh „$h“ „sudo journalctl -u ssh -u sshd –since gestern -o short-iso –no-pager“ > „${h}_sshd.log“ done Das erfordert sudo, um ohne Passwortaufforderung auf der Remote-Seite zu funktionieren. Andernfalls, fügen Sie -t zu ssh hinzu und tippen Sie es jedes Mal ein. Wenn Sie dies mehr als einmal im Quartal tun, schicken Sie die Protokolle stattdessen an ein SIEM.
Ist es sicher, sshd-Protokolle auf ein Online-Tool hochzuladen?
LogTotal bereinigt Uploads vor der Analyse und behält keine Dateien; unser [Bereinigungshandbuch] zeigt, was maskiert wird. Die Datenverarbeitungsregeln Ihrer Organisation haben dennoch Vorrang.
Nächster Schritt
Haben Sie die Datei? Laden Sie es auf LogTotal hoch und sehen Sie, was die 11.632 Sigma-Regeln daraus machen. Wenn Sie dieselbe Erkennungslogik auf allen Ihren Linux-Servern laufen lassen möchten, nicht nur eine Datei zur Zeit.
Referenzen
- Debian 12 Anmerkungen zur Veröffentlichung: Änderungen im System Logging
- OpenSSH 9.8 Anmerkungen zur Veröffentlichung: die sshd / sshd-session Aufteilung und geänderte Protokolltags
- journalctl(1): Einheitsfilter, Ausgabeformate, Journalzugriffsgruppen
- journald.conf(5): dauerhafte vs. flüchtige Speicherung
