Zum Inhalt springen

PersistenzNetzwerkLogs

SSH-Artefakte: authorized_keys, known_hosts und sshd-Logs

OpenSSH-Artefakte unter Linux (authorized_keys, known_hosts, Konfiguration, Host-Keys, sshd-Logs) als Beleg für Fernzugriff, Persistenz und Lateral Movement.

Speicherort
~/.ssh/authorized_keys
Belegt
Welche Schlüssel sich an einem Konto anmelden können, wohin sich ein Benutzer verbunden hat und wer sich von wo per SSH angemeldet hat
Zeitstempel
Schlüsseldateien: nur Dateisystemzeiten; Logs: syslog-Ortszeit oder Journal in Mikrosekunden seit der Unix-Epoche (UTC)
Zugriff
root (oder der Kontoinhaber für das eigene ~/.ssh); Gruppe adm/systemd-journal für Logs
Aufbewahrung
Schlüsseldateien bis zur Löschung; Logzeilen folgen der Syslog-Rotation und den Journal-Limits
Sicherung
UAC, Velociraptor, cp -a, journalctl

Was es ist

OpenSSH hinterlässt Spuren an beiden Enden einer Verbindung. Auf der Serverseite legt authorized_keys fest, welche öffentlichen Schlüssel sich an einem Konto anmelden dürfen, sshd_config setzt die Regeln, und sshd protokolliert jeden erfolgreichen und fehlgeschlagenen Versuch. Auf der Clientseite hält known_hosts die Server fest, mit denen sich ein Benutzer verbunden hat, und ~/.ssh/config benennt sie oft. Zusammen beantworten sie die beiden Kernfragen der meisten Linux-Einbrüche: Wie ist der Angreifer hineingekommen, und wohin ist er danach gegangen?

Einen Schlüssel zu authorized_keys hinzuzufügen gehört zu den häufigsten Persistenztechniken unter Linux (MITRE ATT&CK T1098.004), weil es das Zurücksetzen von Passwörtern übersteht.

Wo es liegt

ArtefaktPfadHinweise
Autorisierte Schlüssel~/.ssh/authorized_keys, ~/.ssh/authorized_keys2Standard-AuthorizedKeysFile; jedes Home-Verzeichnis prüfen, auch /root und Dienstkonten
Bekannte Hosts~/.ssh/known_hosts, /etc/ssh/ssh_known_hostsClientseitige Liste der Server
Hash-Sicherung~/.ssh/known_hosts.oldBleibt von ssh-keygen -H zurück, wenn eine Datei gehasht wird
Client-Konfiguration~/.ssh/config, /etc/ssh/ssh_config, /etc/ssh/ssh_config.d/Host-Aliase, Benutzer, Jump-Hosts, Schlüssel
Benutzerschlüssel~/.ssh/id_*, ~/.ssh/id_*.pubNur Vorhandensein und Fingerprints notieren
Skripte pro Login~/.ssh/rc, /etc/ssh/sshrcVon sshd vor der Shell des Benutzers ausgeführt
Benutzerumgebung~/.ssh/environmentWird nur gelesen, wenn PermitUserEnvironment es erlaubt
Server-Konfiguration/etc/ssh/sshd_config, /etc/ssh/sshd_config.d/*.confDrop-ins über Include in aktuellen Paketen von Debian, Ubuntu und Fedora/RHEL 9
Host-Keys/etc/ssh/ssh_host_{rsa,ecdsa,ed25519}_key(.pub)Identifizieren den Server; neu erzeugte Schlüssel ändern die Fingerprints bei Clients
Logs/var/log/auth.log (Debian/Ubuntu), /var/log/secure (RHEL-Familie), systemd-JournalStandardmäßig Facility AUTH; Konfigurationen der RHEL-Familie setzen AUTHPRIV

Was es belegt

  • Zugriffsmöglichkeit: Jeder Schlüssel in authorized_keys kann sich als dieses Konto anmelden, im Rahmen seiner Optionen und der sshd_config.
  • Tatsächliche Anmeldungen: Zeilen mit Accepted publickey oder Accepted password belegen eine erfolgreiche Authentifizierung mit Quell-IP, Port und (bei Schlüsseln) dem Fingerprint des Schlüssels.
  • Versuche: Failed password, Invalid user und ähnliche Zeilen zeigen Brute-Force-Angriffe und das Erraten von Benutzernamen.
  • Ausgehende Bewegung: known_hosts und ~/.ssh/config zeigen, dass sich das Konto mit anderen Hosts verbunden hat, auch ohne Shell-History.
  • Nicht belegt: Ein Schlüsselkommentar (user@host) ist Freitext, geschrieben von demjenigen, der den Schlüssel erzeugt hat. known_hosts-Einträge tragen kein Datum und zeigen nicht, dass eine Anmeldung gelang, sondern nur, dass ein Host-Key akzeptiert wurde.

Wichtige Felder

Optionen in authorized_keys (kommagetrennt, vor dem Schlüsseltyp):

OptionBedeutung
command="..."Erzwingt für diesen Schlüssel einen Befehl; die ursprüngliche Anfrage steht in SSH_ORIGINAL_COMMAND
from="pattern"Beschränkt Quell-Hosts/-Adressen (CIDR erlaubt)
environment="NAME=value"Setzt Variablen, wenn PermitUserEnvironment aktiviert ist
no-pty, no-port-forwarding, no-agent-forwarding, no-X11-forwarding, no-user-rcEinschränkungen
restrictAlle Einschränkungen auf einmal; lässt sich mit pty, port-forwarding usw. lockern
permitopen=, permitlisten=, tunnel=Steuerung von Weiterleitungen und Tunneln
expiry-time="YYYYMMDD[HHMM[SS]][Z]"Der Schlüssel funktioniert nach diesem Zeitpunkt nicht mehr
cert-authority, principals=Vertrauen in eine CA statt in einen einzelnen Schlüssel

known_hosts: [marker] hostnames keytype base64key [comment]. Gehashte Einträge beginnen mit |1| (Salt und HMAC), die Hostnamen lassen sich also nicht direkt lesen. Debian und Ubuntu liefern HashKnownHosts yes in /etc/ssh/ssh_config aus; der Upstream-Standard ist no.

Direktiven in sshd_config: AuthorizedKeysFile, AuthorizedKeysCommand, AuthorizedPrincipalsFile, TrustedUserCAKeys, PermitRootLogin (Standard prohibit-password), PasswordAuthentication, PermitUserEnvironment (Standard no), ForceCommand, Match-Blöcke, LogLevel (Standard INFO), SyslogFacility.

Logzeilen (Prozess sshd, ab OpenSSH 9.8 auch sshd-session; ab 10.0 können einige Meldungen auch von sshd-auth stammen):

Accepted publickey for deploy from 198.51.100.7 port 51522 ssh2: ED25519 SHA256:<fingerprint>
Accepted password for deploy from 203.0.113.50 port 40318 ssh2
Failed password for invalid user admin from 203.0.113.50 port 40022 ssh2
Invalid user admin from 203.0.113.50 port 40022

Zeitstempel

Schlüssel- und Konfigurationsdateien haben nur Dateisystemzeiten: Die mtime von authorized_keys ändert sich bei jedem Hinzufügen oder Entfernen eines Schlüssels, und die ctime lässt sich mit touch nicht setzen. Syslog-Dateien (auth.log, secure) verwenden die lokale Zeitzone und im klassischen Format kein Jahr; das Journal speichert __REALTIME_TIMESTAMP in Mikrosekunden seit 1970-01-01 UTC. expiry-time-Werte ohne Z werden in der Systemzeitzone ausgewertet.

Aufbewahrung

Schlüsseldateien und Konfigurationen bleiben bis zu einer Änderung erhalten. Die Aufbewahrung der Logs hängt von logrotate ab (wöchentlich mit vier Rotationen ist ein verbreiteter Debian-Standard für auth.log) sowie von den Größenlimits des Journals; siehe syslog und auth.log und systemd-Journal. known_hosts wächst nur, sofern ein Benutzer nicht ssh-keygen -R ausführt oder die Datei bearbeitet.

Sicherung

UAC hat eigene Artefakte für authorized_keys*, known_hosts, öffentliche Schlüssel und ~/.ssh/rc und sammelt /etc/ssh zusammen mit /etc. Velociraptor bietet Linux.Ssh.AuthorizedKeys, Linux.Ssh.KnownHosts und Linux.Syslog.SSHLogin.

R=/mnt/evidence
tar -C "$R" -czf ssh.tgz etc/ssh root/.ssh home/*/.ssh 2>/dev/null   # includes private keys: handle as sensitive
journalctl -D "$R"/var/log/journal _COMM=sshd -o short-iso        # add _COMM=sshd-session on newer OpenSSH

Behandeln Sie private Host- und Benutzerschlüssel als sensible Beweismittel: Fingerprints dokumentieren, Zugriff beschränken, niemals wiederverwenden.

Auswertung

# fingerprint every authorized key, then match against "Accepted publickey" lines
for f in /mnt/evidence/root/.ssh/authorized_keys* /mnt/evidence/home/*/.ssh/authorized_keys*; do
  echo "== $f"; ssh-keygen -l -f "$f"; done
grep -hE 'sshd(-session|-auth)?\[[0-9]+\]: (Accepted|Failed|Invalid user)' /mnt/evidence/var/log/auth.log* /mnt/evidence/var/log/secure*
zgrep -h 'Accepted' /mnt/evidence/var/log/auth.log.*.gz
# test a candidate hostname against a hashed known_hosts
ssh-keygen -F 10.0.0.12 -f /mnt/evidence/home/alice/.ssh/known_hosts

Linux Log Parser liest auth.log / secure, syslog, Journal-Dateien, audit.log und wtmp / btmp / lastlog im Browser und führt sie in einer Zeitleiste mit rekonstruierten Login-Sitzungen zusammen; es wird nichts hochgeladen.

Tipps für die Untersuchung

  • Ordnen Sie den SHA256:-Fingerprint jeder Accepted publickey-Zeile einer bestimmten Schlüsselzeile zu; so erkennen Sie, welchen Schlüssel ein Angreifer verwendet hat, auch wenn die Kommentare gefälscht sind.
  • Suchen Sie in sshd_config und jedem Drop-in nach einem AuthorizedKeysFile, das auf einen ungewöhnlichen Pfad zeigt, oder nach einem AuthorizedKeysCommand: Schlüssel können außerhalb von ~/.ssh liegen.
  • Schlüssel mit command= und ~/.ssh/rc führen bei jeder Anmeldung Code aus; eine from=-Option kann Infrastruktur des Angreifers verraten.
  • Parser oder SIEM-Regeln, die nur auf sshd[ prüfen, übersehen bei aktuellem OpenSSH Zeilen mit dem Tag sshd-session oder sshd-auth (Velociraptors Linux.Syslog.SSHLogin filtert auf das Programm sshd).
  • Gehashte known_hosts lassen sich mit ssh-keygen -F trotzdem gegen Kandidaten-IPs aus Ihrem Fall prüfen.
  • Geänderte Host-Keys (neue ctime bei /etc/ssh/ssh_host_*) können auf einen neu aufgesetzten oder geklonten Server hinweisen.
  • Korrelieren Sie erfolgreiche Anmeldungen mit wtmp/lastlog und der Shell-History des Benutzers.

Siehe auch