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 existieren, protokolliert Ihr System nur im systemd-Journal. Dann ist der Befehl, den Sie wollen, journalctl -u ssh auf Debian-basierten Systemen oder journalctl -u sshd auf der Red Hat-Familie, Fedora und Arch.
SSH ist die Eingangstür zu fast jedem Linux-Server, weshalb seine Protokolle bei fast jeder Linux-Untersuchung auftauchen. Prime Core hat 11.632 Sigma-Regeln, die auf Linux-Authentifizierungsprotokollen wie diesen laufen und auf 643 MITRE ATT&CK-Techniken abgebildet sind. Unter ihnen: Brute Force (T1110), Anmeldungen mit gestohlenen Anmeldedaten (T1078) und laterale Bewegung über SSH (T1021.004). Unten erfahren Sie, wie Sie Ihre sshd-Protokolle finden, exportieren, bereinigen und kostenlos in LogTotal untersuchen können.
Probieren Sie LogTotal kostenlos aus
Zusammenfassung
| Familie der Distribution | Protokolldatei | Journalbefehl |
|---|---|---|
| Debian, Ubuntu | /var/log/auth.log | journalctl -u ssh |
| RHEL, Rocky, Alma, CentOS Stream | /var/log/secure | journalctl -u sshd |
| Fedora, Arch, Minimal-Installationen ohne rsyslog | Standardmäßig keine | journalctl -u sshd |
Bevor Sie beginnen: Können Sie sie tatsächlich lesen?
Authentifizierungsprotokolle sind absichtlich gesperrt, sodass ein reguläres Konto normalerweise nichts zurückbekommt.
- /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 Nachrichten von anderen Benutzern nicht sehen. Das sind Berechtigungen, kein ruhiger Server.
Die einfache Lösung ist sudo. Wenn Sie ein Konto nur für die Protokollsammlung einrichten, fügen Sie es adm oder systemd-journal hinzu, anstatt root zu vergeben. Unser [Linux-Protokollberechtigungen-Leitfaden] behandelt die Details.
Noch eine Sache, bevor Sie etwas von einem Server kopieren: Auth-Protokolle enthalten Benutzernamen, Quell-IP-Adressen und Hostnamen. LogTotal bereinigt Uploads, aber überprüfen Sie zuerst Ihre Datenhandhabungsrichtlinien.
Schritt 1: Datei, Journal oder beides?
Die obige Tabelle zeigt die Standardwerte, und genau diese ändern Cloud-Images und Härtungsskripte gerne. Verbringen Sie zehn Sekunden damit, folgendes zu überprüfen:
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
systemctl is-active rsyslog
Wenn eine Datei auftaucht und rsyslog aktiv ist, haben Sie beides: rsyslog kopiert Nachrichten aus dem Journal in eine einfache Textdatei. Beide Quellen funktionieren, und die Datei ist einfacher herumzukopieren.
Wenn es keine Datei gibt, ist rsyslog einfach nicht installiert. Das ist jetzt die Norm: Seit Debian 12 ist rsyslog nicht mehr Teil einer Standardinstallation, sodass eine neue Debian-Box überhaupt kein auth.log hat. Fedora und Arch arbeiten seit Jahren so. Gehen Sie zu Schritt 2b.
Während Sie hier sind, überprüfen Sie, ob das Journal einen Neustart überlebt:
ls -d /var/log/journal
Wenn dieses Verzeichnis nicht existiert, speichert journald Protokolle im Speicher unter /run/log/journal, und ein Neustart löscht sie. Auf einer Maschine, die Sie untersuchen, ist es wissenswert, bevor jemand entscheidet, sie „einfach neu zu starten“.
Ein weiterer Punkt für den Vorfall: Wenn der Kasten kompromittiert sein könnte, sind möglicherweise auch seine lokalen Protokolle betroffen. Das Löschen oder Bearbeiten von auth.log ist ein klassischer Aufräumschritt. Wenn der Server Protokolle an ein SIEM weiterleitet, exportieren Sie sie auch von dort und vergleichen Sie. Unser [Splunk-Export-Leitfaden] zeigt, wie.
Schritt 2a: Export aus auth.log oder secure
Die aktuelle Datei deckt nur die letzten Tage ab. Ältere Einträge befinden sich in den daneben gedrehten Dateien. 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 begonnen hat, brauchen Sie diese auch.
Dies zieht sshd-Zeilen aus den aktuellen und gedrehten Dateien, von der ältesten bis zur neuesten, in eine Datei zusammen:
# 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 unkomprimierte als auch komprimierte Dateien, sodass Sie nichts entpacken müssen. ls -tr sortiert nach Änderungszeit, sodass die älteste Datei zuerst kommt und die Ausgabe grob chronologisch bleibt. Das sshd-Muster passt auch zu sshd-session, was auf neueren Systemen von Bedeutung ist (siehe Schritt 2b).
Warum überhaupt filtern? Neben der Rauschunterdrückung zeichnet auth.log auch sudo auf, und sudo-Zeilen enthalten vollständige Befehlszeilen. Gelegentlich geben Leute Passwörter ein. Das Filtern auf sshd hält das aus der Datei heraus. Die Ausnahme ist, wenn Sie untersuchen, was ein Angreifer getan hat nachdem er sich eingeloggt hat. Dann wollen Sie auch die sudo-Zeilen: Nehmen Sie die gesamte Datei und lassen Sie LogTotals Bereinigungsprozess seine Arbeit machen.
Schnelle Überprüfung, bevor Sie 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, notieren Sie sich die Zeitzone des Servers (timedatectl). Sie brauchen es in dem Moment, in dem Sie versuchen, diese Ereignisse mit etwas anderem abzustimmen.
Schritt 2b: Export aus dem systemd-Journal
Auf journal-only-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.
Beide Einheitsnamen. Der Dienst heißt ssh auf Debian und Ubuntu und fast überall sonst sshd. journalctl kombiniert wiederholte -u-Flags mit ODER, sodass derselbe Befehl auf beiden Familien funktioniert.
Nach Einheit filtern, nicht nach Tag. Viele ältere Anleitungen verwenden journalctl -t sshd. Seit OpenSSH 9.8 ist der Server in zwei Binärdateien aufgeteilt, und pro-Verbindungsnachrichten, einschließlich Anmeldungen, sind mit sshd-session anstatt sshd gekennzeichnet. Filtern Sie nach Tag, und Sie verlieren genau die Zeilen, nach denen Sie gekommen sind. Dies brach viele fail2ban- und sshguard-Setups, als 9.8 im Jahr 2024 auf den Markt kam. RHEL 10 und andere aktuelle Veröffentlichungen liefern OpenSSH 9.8 oder neuer. Das Filtern nach Einheit erfasst jeden Prozess, der zum Dienst gehört, unabhängig davon, wie er heißt.
-o short-iso. Es gibt Ihnen eine Syslog-ähnliche Zeile mit einem vollständigen ISO 8601 Zeitstempel, Jahr und Zeitzone inbegriffen, sodass Sie nicht raten müssen. [PROOF: bestätigen, dass LogTotal short-iso parst; wenn nicht, verwenden Sie das Standard -o short]. Wenn Sie lieber jedes Journalfeld behalten möchten (PID, Boot-ID, Hostname usw.), verwenden Sie -o json, was ein JSON-Objekt pro Zeile schreibt. Die Datei wird größer, aber nichts geht verloren.
Die Zeitfilter nehmen auch relative Werte an: –since „vor 2 Stunden“ oder –since gestern. Mit einem persistenten Journal begrenzt -b -1 die Ausgabe auf den vorherigen Boot, was hilft, wenn der Server nach dem Vorfall neu gestartet wurde.
Kopieren Sie die binären .journal Dateien aus /var/log/journal nicht und laden Sie diese nicht hoch. LogTotal liest Text und JSON, und Journaldateien sind keines von beidem.
Worauf Sie achten sollten, wenn 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 einen vorhandenen Account |
| Ungültiger Benutzer <user> von <ip> | Der Benutzername existiert nicht; typisch für Scanner, die sich durch admin, test, oracle arbeiten |
| Akzeptiertes Passwort für / Akzeptierter Publickey für | Eine erfolgreiche Anmeldung; die publickey-Zeile 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 Banner-Grabs |
| pam_unix(sshd:session): Sitzung für Benutzer geöffnet | Die Sitzung hat tatsächlich begonnen |
Die Sequenz, die es wert ist, gestoppt zu werden: eine Reihe von Fehlgeschlagenen oder Ungültiger Benutzer-Zeilen von einer IP, dann ein Akzeptiert von derselben IP. Das ist ein Brute-Force, die funktioniert hat. Dicht dahinter: ein Akzeptiert für ein Dienstkonto, von einer Adresse, die niemand erkennt, zu einer Uhrzeit, zu der niemand arbeitet.
Auf OpenSSH 9.8 und höher können Sie auch Nachrichten über Sanktionen sehen: sshd verweigert temporär Adressen, die immer wieder bei der Authentifizierung scheitern. Behandeln Sie sie als Symptom. Sie zeigen Ihnen, dass jemand den Port hämmerte, nicht dass jemand hereingekommen ist.
Hochladen, bereinigen und in LogTotal überprüfen
Ein paar hundert Zeilen per Auge zu lesen ist in Ordnung. 40.000 zu lesen nicht. LogTotal ist der kostenlose Dienst von SOC Prime, um Erkennungslogik gegen eine Protokolldatei auszuführen, ohne etwas einzurichten. Es bereinigt das, was Sie hochladen, und behält Ihre Dateien nicht.
- Hochladen. Öffnen logtotal.com und fügen Sie web-03_sshd.log hinzu. [PROOF: Upload-Bildschirm, Größengrenze]
- Bereinigen. [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.
- Überprüfen. [PROOF: what the results screen shows and how findings map to rules and ATT&CK techniques]
Wie das bei realen Daten aussieht. Wir haben sshd-Protokolle auf einer Wegwerftest-VM generiert: [PROOF: was simuliert wurde, z.B. ein SSH-Passwortspraying gegen einige gängige Benutzernamen, das in einem erfolgreichen Login endet]. Die Datei hatte [PROOF: N Zeilen, X KB]. LogTotal markierte [PROOF: tatsächliche Befunde, übereinstimmende Regeln, ATT&CK-Techniken].
Möchten Sie es ausprobieren, bevor Sie Ihre eigenen Server anrühren? [PROOF: Link zur Beispieldatei] ist dieselbe Datei, die wir oben verwendet haben.
Wenn es schief geht
| 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 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 zur systemd-journal hinzu |
| journalctl -u ssh gibt nichts als root zurück | Falscher Einheitsname für diese Distribution | Verwenden Sie -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; keine /var/log/journal | Die alten Protokolle sind weg; überprüfen Sie Ihr SIEM oder das Log-Weiterleitungsgerät |
| Die Datei deckt nur einige Tage ab | Gedrehte Dateien wurden nicht einbezogen | Verwenden Sie den zgrep-Befehl mit auth.log* oder secure* |
| Zeitstempel stimmen nicht mit anderen Quellen überein | Klassische Syslog-Zeitstempel enthalten 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, plus das Journal (journalctl -u ssh). Minimale Cloud-Images lassen manchmal rsyslog 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 mehr als nur einen kurzen Blick, laden Sie stattdessen das vollständige sshd-Protokoll hoch. Die Fehler bedeuten nur etwas neben den Erfolgen.
Was ist mit last und lastb?
Sie lesen die binären Anmeldeprotokolle in /var/log/wtmp und /var/log/btmp. Sie sind praktisch für einen schnellen Blick darauf, wer sich angemeldet hat, tragen aber weit weniger Details als sshds eigenes Protokoll und sind genauso einfach für einen Eindringling zu fälschen.
Wie sammle ich sshd-Protokolle von mehreren Servern gleichzeitig?
Für eine einmalige Aktion macht das eine Schleife: 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 Das setzt voraus, dass sudo ohne Passwortabfrage auf der Remote-Seite funktioniert. Andernfalls fügen Sie -t zu ssh hinzu und geben es jedes Mal ein. Wenn Sie dies mehr als einmal im Quartal tun, senden Sie die Protokolle stattdessen an ein SIEM.
Ist es sicher, sshd-Protokolle zu einem Online-Tool hochzuladen?
LogTotal bereinigt Uploads vor der Analyse und behält keine Dateien; unser [Bereinigungshandbuch] zeigt, was maskiert wird. Die Datenhandhabungsregeln Ihrer Organisation kommen jedoch immer zuerst.
Nächster Schritt
Haben Sie die Datei? Laden Sie sie zu LogTotal hoch und sehen Sie, was diese 11.632 Sigma-Regeln daraus machen. Wenn Sie dieselbe Erkennungslogik auf all Ihren Linux-Servern und nicht nur auf einer Datei gleichzeitig laufen lassen möchten.
Quellen
- Debian 12 Veröffentlichungsnotizen: Änderungen an der Systemprotokollierung
- OpenSSH 9.8 Veröffentlichungsnotizen: die Aufteilung sshd / sshd-session und geänderte Protokoll-Tags
- journalctl(1): Einheitsfilter, Ausgabeformate, Journalzugriffsgruppen
- journald.conf(5): Persistente vs. flüchtige Speicherung
