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
- Hash ExtractorBrowser
- Linux Log ParserBrowser
- ssh-keygenCLI · in Linux enthalten
- VelociraptorPlattform · Open Source
- UACCLI · Open Source
- grep / zgrepCLI · in Linux enthalten
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
| Artefakt | Pfad | Hinweise |
|---|---|---|
| Autorisierte Schlüssel | ~/.ssh/authorized_keys, ~/.ssh/authorized_keys2 | Standard-AuthorizedKeysFile; jedes Home-Verzeichnis prüfen, auch /root und Dienstkonten |
| Bekannte Hosts | ~/.ssh/known_hosts, /etc/ssh/ssh_known_hosts | Clientseitige Liste der Server |
| Hash-Sicherung | ~/.ssh/known_hosts.old | Bleibt 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_*.pub | Nur Vorhandensein und Fingerprints notieren |
| Skripte pro Login | ~/.ssh/rc, /etc/ssh/sshrc | Von sshd vor der Shell des Benutzers ausgeführt |
| Benutzerumgebung | ~/.ssh/environment | Wird nur gelesen, wenn PermitUserEnvironment es erlaubt |
| Server-Konfiguration | /etc/ssh/sshd_config, /etc/ssh/sshd_config.d/*.conf | Drop-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-Journal | Standardmäßig Facility AUTH; Konfigurationen der RHEL-Familie setzen AUTHPRIV |
Was es belegt
- Zugriffsmöglichkeit: Jeder Schlüssel in
authorized_keyskann sich als dieses Konto anmelden, im Rahmen seiner Optionen und dersshd_config. - Tatsächliche Anmeldungen: Zeilen mit
Accepted publickeyoderAccepted passwordbelegen eine erfolgreiche Authentifizierung mit Quell-IP, Port und (bei Schlüsseln) dem Fingerprint des Schlüssels. - Versuche:
Failed password,Invalid userund ähnliche Zeilen zeigen Brute-Force-Angriffe und das Erraten von Benutzernamen. - Ausgehende Bewegung:
known_hostsund~/.ssh/configzeigen, 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):
| Option | Bedeutung |
|---|---|
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-rc | Einschränkungen |
restrict | Alle 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 jederAccepted 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_configund jedem Drop-in nach einemAuthorizedKeysFile, das auf einen ungewöhnlichen Pfad zeigt, oder nach einemAuthorizedKeysCommand: Schlüssel können außerhalb von~/.sshliegen. - Schlüssel mit
command=und~/.ssh/rcführen bei jeder Anmeldung Code aus; einefrom=-Option kann Infrastruktur des Angreifers verraten. - Parser oder SIEM-Regeln, die nur auf
sshd[prüfen, übersehen bei aktuellem OpenSSH Zeilen mit dem Tagsshd-sessionodersshd-auth(VelociraptorsLinux.Syslog.SSHLoginfiltert auf das Programmsshd). - Gehashte
known_hostslassen sich mitssh-keygen -Ftrotzdem 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
Verwandte Artefakte
Ausführliche Leitfäden
Glossar
- wtmp and btmpEnglisch
- systemd Journal (journald)Englisch