Das SSH-Authentifizierungsprotokoll lesen: was jede Fehlerzeile bedeutet

Wo das Protokoll wirklich liegt

Daran scheitert man zuerst, denn es hängt von der Distribution ab. Debian und Ubuntu schreiben Authentifizierungsereignisse nach /var/log/auth.log. RHEL, CentOS, AlmaLinux, Rocky und Fedora nach /var/log/secure. Systeme, die vollständig auf journald umgestellt haben, besitzen womöglich keine der beiden Dateien, und alles liegt im Journal.

Die portable Antwort ist journalctl, das überall funktioniert, wo systemd läuft:

# Portabel: sshds eigenes Journal live mitlesen
journalctl -u ssh -f          # Unit-Name unter Debian/Ubuntu
journalctl -u sshd -f         # Unit-Name unter RHEL/Fedora

# Nur Fehlschläge, letzte 24 Stunden
journalctl -u ssh --since -24h | grep -E 'Failed|Invalid user'

# Auf Distributionen, die die Datei noch schreiben:
grep -E 'Failed|Invalid user' /var/log/auth.log     # Debian/Ubuntu
grep -E 'Failed|Invalid user' /var/log/secure       # RHEL-Familie

Die Meldungsvarianten, entschlüsselt

sshd gibt eine kleine Menge Fehlermeldungen aus, und jede bedeutet etwas Bestimmtes. Diese fünf decken fast alles ab, was Sie sehen werden:

• Failed password for <user> from <ip> port <n> ssh2 — das Konto existiert, das Passwort war falsch. Entweder ein echter Nutzer mit Tippfehler oder ein Bot, der einen gültigen Namen erraten hat.
• Failed password for invalid user <user> from <ip> — das Konto existiert nicht. Fast immer ein Angriff: Ihre eigenen Nutzer kennen ihre Benutzernamen. Meist begleitet von einer separaten „Invalid user"-Zeile.
• Connection closed by authenticating user <user> <ip> port <n> [preauth] — der Client hat mitten in der Authentifizierung aufgegeben. Typisch für Scanner, die nur den Banner erfassen wollten, und für Keys-only-Server, die Passwortversuche abweisen.
• Disconnected from authenticating user root <ip> port <n> [preauth] — ein Root-Anmeldeversuch auf einem Server, wo root untersagt ist. Hohes Volumen hier ist die häufigste Signatur auf einem exponierten Host.
• Maximum authentication attempts exceeded for <user> from <ip> — der Client hat MaxAuthTries in einer Verbindung ausgereizt. Oft ein Agent, der viele Schlüssel anbietet, von einer unbekannten Adresse aber ein Bot, der Zugangsdaten durchgeht.

Angriff von Tippfehler unterscheiden

Drei Signale trennen sie, und vor automatischem Handeln wollen Sie alle drei.

Rate und Ausdauer. Ein Mensch macht zwei bis drei Versuche in einer Minute und kommt dann entweder rein oder ruft Sie an. Ein Bot hält stundenlang eine konstante Rate, die ganze Nacht, ohne Pause.

Kontovielfalt. Ein Mensch probiert ein Konto: sein eigenes. Ein Bot arbeitet eine Liste ab, und die meisten dieser Konten existieren nicht — genau die „invalid user"-Signatur von oben.

Quelle. Ihre Leute verbinden sich von einer Handvoll bekannter Adressen. Angriffe kommen aus Hosting-Bereichen, alle paar hundert Versuche von einer anderen Adresse, oft aus mehreren Ländern in derselben Stunde.

Dies gruppiert die Fehlschläge des letzten Tages nach Quelladresse und zeigt, welche Benutzernamen jede probiert hat — alle drei auf einen Blick:

journalctl -u ssh --since -24h --no-pager |
  grep -oE 'Failed password for (invalid user )?[^ ]+ from [0-9.]+' |
  awk '{ ip = $NF; user = $(NF-2); count[ip]++; users[ip] = users[ip] " " user }
       END { for (i in count) printf "%6d  %-16s %s\n", count[i], i, users[i] }' |
  sort -rn | head -15

Die Zeile, auf die Sie wirklich alarmieren sollten

Fehlanmeldungen sind Rauschen. Eine Meldung ist es nicht, und sie verdient einen Alarm statt eines Dashboards:

Accepted password for <user> from <ip> — eine erfolgreiche Passwortanmeldung. Wenn Ihr Server Keys-only sein sollte, bedeutet diese Zeile, dass er es nicht ist, und Sie haben ein Konfigurationsproblem. Sind Passwörter erlaubt, ist diese Zeile von einer unbekannten Adresse direkt nach einer Serie von Fehlschlägen aus demselben Bereich die Abfolge, die Sie nie sehen wollen.

Daneben beobachtenswert: Accepted publickey mit einem Fingerabdruck, den Sie nicht kennen, und jede sudo-Sitzung eines Nutzers, der keine haben sollte. Beides ist billig zu alarmieren und beides zählt weit mehr als die Menge der Abweisungen.

# Alle erfolgreichen Anmeldungen der letzten Woche, mit Methode und Quelle
journalctl -u ssh --since -7d --no-pager |
  grep -E 'Accepted (password|publickey|keyboard-interactive)'

Vom Lesen zum Blockieren

Das Protokoll von Hand zu lesen ist Diagnose, keine Abwehr — wenn Sie die Abfrage ausführen, läuft der Angriff schon eine Woche. Etwas ändert nur, wer es laufend tut und eine Schwelle in eine Firewall-Regel übersetzt.

Die naive Variante liest das Journal, zählt Fehlschläge pro Quelle und ruft nft auf, um die Adresse in ein Sperrset aufzunehmen. Das funktioniert — und trifft dann die Probleme, die jedes solche Skript trifft: Das Set wächst unbegrenzt, das Protokoll rotiert unter Last und Ereignisse gehen verloren, die Unit stirbt nach einem Upgrade still, und ein Fehltreffer sperrt den Administrator vom einzigen Zugang aus.

SSH Protector führt diese Schleife als Dienst aus, mit einem zusammengefassten nftables-Set, einer Whitelist, die jede Sperre schlägt, Sperren, die beim Booten wiederhergestellt werden, und lokal getroffener Entscheidung — sie hält also, wenn das Netz nicht hält. Er liest denselben Strom, der oben gezeigt wird; nichts bleibt Ihnen verborgen.