WardtermSSH-Client
DE
Herunterladen

SSH-Anmeldeversuche unter Linux prüfen

Führen Sie unter Debian und Ubuntu sudo journalctl -u ssh --since today aus, unter Red Hat und Fedora -u sshd. Wo es Textlogs gibt, schauen Sie in /var/log/auth.log oder /var/log/secure. Zeilen mit Accepted sind echte Anmeldungen, Failed password oder Invalid user sind Versuche. Nutzen Sie who für aktuelle Sitzungen, last für vergangene und sudo lastb für Fehlschläge, wo diese Befehle existieren.

Unsicher, ob dieser Server das Journal oder auth.log nutzt? „Ask“ in Wardterm liefert den Befehl für sein System. Zeigen

Aktualisiert am . Logzeilen und grep-Befehle wurden mit OpenSSH 10.0 unter Debian 13 mit rsyslog ausgeführt.

Wo die Logs liegen

SystemLogs lesen mit
Debian oder Ubuntu, mit systemdsudo journalctl -u ssh
Red Hat oder Fedora, mit systemdsudo journalctl -u sshd
Debian oder Ubuntu mit rsyslog/var/log/auth.log
Red-Hat-Familie mit rsyslog/var/log/secure

Eine Datei kann fehlen, und das ist normal: Debian installiert rsyslog seit Version 12 nicht mehr standardmäßig, ein neues Debian-System hat daher oft nur das Journal.

Mit journalctl

sudo journalctl -u ssh --since today
sudo journalctl -u ssh --since "2 hours ago" --grep 'Accepted|Failed|Invalid'
sudo journalctl -u ssh -f

-f verfolgt neue Zeilen, sobald sie eintreffen, was beim Testen einer Anmeldung hilft.

Mit den Textdateien

sudo grep Accepted /var/log/auth.log
sudo grep -E 'Failed password|Invalid user' /var/log/auth.log

Ältere Zeilen stehen vielleicht in /var/log/auth.log.1 und in komprimierten Dateien daneben. Seit OpenSSH 9.8 tragen diese Zeilen den Namen sshd-session statt sshd, ein Filter oder Skript, das nach sshd[ sucht, findet auf einem aktuellen System also nichts.

Was die Zeilen bedeuten

Alle folgenden Zeilen stammen von einem Testserver, die Adresse wurde geändert.

sshd-session[1329]: Accepted publickey for user from 203.0.113.10 port 43594 ssh2: ED25519 SHA256:NxFS05Q+k1zf...
sshd-session[1339]: Accepted password for user from 203.0.113.10 port 43598 ssh2

Jemand hat sich angemeldet. Diese Zeilen lesen Sie zuerst. Die erste zeigt, welcher Schlüssel benutzt wurde. Siehe Schlüssel widerrufen, falls Sie einen finden, den Sie nicht wollen.

sshd-session[1311]: Failed password for user from 203.0.113.10 port 33598 ssh2

Ein falsches Passwort für ein Konto, das existiert.

sshd-session[1317]: Invalid user admin from 203.0.113.10 port 50898
sshd-session[1317]: Failed password for invalid user admin from 203.0.113.10 port 50898 ssh2

Ein Versuch an einem Konto, das auf diesem System nicht existiert. So sieht das meiste automatische Raten aus.

sshd-session[1326]: Connection closed by authenticating user user 203.0.113.10 port 43590 [preauth]

Der Client hat während der Anmeldung aufgegeben. Bei Schlüssel-Anmeldungen heißt das meist, dass ein Schlüssel angeboten und nicht akzeptiert wurde. Standardmäßig steht im Log nicht, welcher.

sshd-session[1317]: error: maximum authentication attempts exceeded for invalid user admin from 203.0.113.10 port 50898 ssh2 [preauth]

Der Client hat MaxAuthTries überschritten und wurde getrennt.

Versuche nach Adresse und Benutzer zählen

# Which addresses
sudo grep -E 'Failed password|Invalid user' /var/log/auth.log \
  | grep -oE 'from [0-9a-f.:]+' | sort | uniq -c | sort -rn | head -20

# Which user names they try
sudo grep -oE 'Invalid user [^ ]+' /var/log/auth.log \
  | awk '{print $3}' | sort | uniq -c | sort -rn | head -20

Ein einzelner Versuch erzeugt meist eine Failed- und eine Invalid user-Zeile, sehen Sie die Zahlen also als Richtwert. Mit dem Journal beginnen Sie die erste Pipeline so:

sudo journalctl -u ssh --since today --no-pager | grep -E 'Failed password|Invalid user' \
  | grep -oE 'from [0-9a-f.:]+' | sort | uniq -c | sort -rn | head -20

Sehen, wer gerade angemeldet ist

who
w

Beide listen Sitzungen mit Terminal auf. Ein Befehl, der als ssh server somecommand läuft, eine Dateiübertragung oder ein Tunnel erscheint nicht. Um alle Verbindungen zu sehen, auch diese:

sudo ss -tnp state established '( sport = :22 )'

Ändern Sie 22, wenn Ihr Server einen anderen Port nutzt. Wir sahen die Verbindung in dieser Liste, als who nichts zeigte.

Vergangene Sitzungen: last und lastb

last -a -n 20
sudo lastb -a -n 20

last liest vergangene Anmeldungen und lastb die fehlgeschlagenen. -a setzt die Adresse in die letzte Spalte. In unseren Tests ergaben sich zwei Grenzen:

  • last zeigte nur Sitzungen mit Terminal. Eine Anmeldung, die nur einen Befehl ausführte, hinterließ nichts, die Logdateien sind also die vollständigere Aufzeichnung.
  • Unter Debian 13 gibt es diese Befehle nicht mehr. Das Paket util-linux enthält last und lastb nicht mehr. Installieren Sie wtmpdb und libpam-wtmpdb, um last zurückzubekommen, was in unserem Test funktionierte, für Sitzungen nach der Installation. Für Fehlschläge gibt es keinen Ersatz, der die alte Datei liest. Die Versionshinweise empfehlen lslogins --failed, das in unserem Test aber nichts zeigte, nutzen Sie also die Logs.

Sehen, welcher Schlüssel abgelehnt wurde

Um auch den Fingerabdruck fehlgeschlagener Schlüssel zu protokollieren, setzen Sie dies in eine Datei in /etc/ssh/sshd_config.d/ und laden neu:

LogLevel VERBOSE
sshd-session[1376]: Failed publickey for user from 203.0.113.10 port 43612 ssh2: RSA SHA256:R3PypHnQ7AMz...

Was Sie mit dem Gefundenen tun

  • Viele Fehlschläge von vielen Adressen: Das ist auf jedem Server, der im Internet erreichbar ist, üblich. Akzeptiert der Server nur Schlüssel, können Passwort-Versuche nicht gelingen. Siehe Passwort-Anmeldung abschalten und, um das Rauschen zu verringern, fail2ban.
  • Eine Accepted-Zeile, die Sie nicht erklären können: Nehmen Sie das ernst. Notieren Sie Zeit, Adresse und Schlüssel. Entziehen Sie diesen Zugang, sehen Sie nach, was das Konto getan hat, und wenn Sie nicht sicher sind, was passiert ist, bauen Sie den Server aus einem sauberen Zustand neu auf.

Wer Root hat, kann lokale Logs bearbeiten. Schicken Sie sie bei wichtigen Servern deshalb zusätzlich an eine andere Maschine.

Damit Passwortraten ins Leere läuft, erzeugen Sie einen Ed25519-SSH-Schlüssel und lassen nur Schlüssel zu.

Fragen

Wie sehe ich fehlgeschlagene SSH-Anmeldeversuche?

Auf Systemen mit systemd mit sudo journalctl -u ssh --grep 'Failed|Invalid' (sshd unter Red Hat). Bei Textlogs suchen Sie mit grep nach 'Failed password' in /var/log/auth.log oder /var/log/secure. sudo lastb listet Fehlversuche, wo es installiert ist.

Wo liegt das SSH-Log unter Ubuntu?

Im Journal, lesbar mit sudo journalctl -u ssh, und in /var/log/auth.log, wenn rsyslog installiert ist, was unter Ubuntu standardmäßig der Fall ist.

Sind viele fehlgeschlagene SSH-Anmeldungen ein Problem?

Auf einem öffentlichen Server sind sie das übliche Grundrauschen von Bots und bleiben erfolglos, wenn nur Schlüssel akzeptiert werden. Handeln sollten Sie bei einer Accepted-Zeile, die Sie nicht erklären können.

Quellen

Mehr zu Server absichern

Alle Anleitungen