(See below for english version)

# Kompromittierte SSH-Keys behandeln

## Grundsätzliches zu SSH-Schlüsseln

Wir gehen im Folgenden davon aus dass [OpenSSH](https://www.openssh.com/) unter einer unixoiden Umgebung (Linux, BSD, macOS, Cygwin, Linux Subsystem for Windows, …) benutzt wird, da OpenSSH die am weitesten verbreitete SSH-Implementierung ist. Windows-Benutzer verwenden häufig [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/), hier geben wir wenn möglich die entsprechenden Unterschiede an. Benutzer anderer SSH-Clients müssen gegebenenfalls die Dokumentation ihrer Software konsultieren.

SSH-Schlüssel sind ein Authentifizierungsverfahren für das SSH-Protokoll. SSH-Schlüssel sind ein [asymmetrisches Kryptosystem](https://de.wikipedia.org/wiki/Asymmetrisches_Kryptosystem), jedes Schlüssel*paar* besteht aus einem öffentlichen und einem privaten Schlüssel. Diese werden mit [ssh-keygen](https://man.openbsd.org/ssh-keygen.1) ([puttygen](https://tartarus.org/~simon/putty-snapshots/htmldoc/Chapter8.html#pubkey) bei PuTTY) erzeugt und unter `$HOME/.ssh/` gespeichert (puttygen/PuTTY haben keinen Standardort an dem Schlüssel hinterlegt werden). Die Dateinamen der Schlüssel beginnen – sofern nicht vom Benutzer geändert – mit `id_` gefolgt vom verwendeten Cryptoverfahren. Öffentliche Schlüssel heissen wie der dazugehörige private Schlüssel mit dem Suffix `.pub`. Mittels `grep -l -r 'BEGIN OPENSSH PRIVATE KEY' $HOME/.ssh/` kann man alle existierenden SSH-Schlüssel suchen. Private keys bei PuTTY haben die Endung `.ppk`.

Zum Schutz gegen Verlust oder Diebstahl sollten SSH-Schlüssel nur mit einem starken Passwort verschlüsselt abgelegt werden. Um dieses nicht bei jeder Benutzung eingeben zu müssen wird oft ein [ssh-agent](https://en.wikipedia.org/wiki/Ssh-agent)) eingesetzt. Dieser entschlüsselt initial den privaten Schlüssel, hält diesen für die Dauer der Sitzung im Speicher und stellt ihn für alle folgenden SSH-Verbindungen vor. Mittels *agent forwarding* (Option `-A` bzw. `ForwardAgent`) kann der private Schlüssel über den ssh-agent auch in entfernten Sitzungen genutzt werden. Die [Dokumentation](https://man.openbsd.org/ssh) warnt ausdrücklich vor den damit verbundenen Sicherheitsrisiken.

## Szenario 1: privater Schlüssel auf HPC-Systemen gespeichert

Private Schlüssel auf kompromittierten Rechnern sollten grundsätzlich ebenfalls als kompromittiert betrachtet werden. Passwörter helfen hier nur beschränkt, da ein Angreifer diese potentiell über veränderte Software oder direkt aus dem Speicher auslesen kann. Das Gleiche gilt für alle Rechner, auf die mit den kompromittierten Schlüssel zugegriffen werden konnte. Ein Angreifer kann aus der Shell-Historie und der `known_hosts`-Datei von ssh weitere extrahieren.

### Mitigation durch den Benutzer

* betroffene public keys überall aus `$HOME/.ssh/authorized_keys` löschen
* potentiell betroffene Systeme auf Kompromittierung prüfen bzw. das Problem dem Betreiber melden

## Szenario 2: Kein privater Schlüssel auf HPC-Systemen gespeichert; Zugriff mittels ssh-agent mit agent forwarding

Ein Angreifer kann sich während einer laufenden Sitzung Zugriff auf den ssh-agent verschaffen und sich damit auf weitere Systeme verbinden. Der private Schlüssel wird damit nicht kompromittiert, solange keine Rückverbindung möglich ist.

### Mitigation durch den Benutzer

* potentiell betroffene Systeme auf Kompromittierung prüfen bzw. das Problem dem Betreiber melden

## Szenario 3: Kein privater Schlüssel auf HPC-Systemen gespeichert; Zugriff mittels ssh-agent ohne agent forwarding

Hierbei wird kein SSH-Schlüssel kompromittiert

# How to handle (potentially) compromized ssh keys

(short version)

## scenario 1: private keys stored on compromised machines

If you stored your private ssh keys (usually in `$HOME/.ssh/id_*`) on a compromised machine consider them also compromised and act accordingly:

* remove the corresponding public key from all other machines (delete the corresponding lines in `$HOME/.ssh/authorized_keys`)
* retire the affected ssh-keys
* inform the mechine's administration that your account on their machine may have be compromised

## scenario 2: no private key on compromised machines, access via ssh-agent with forwarding enabled

You private key is not compromised but an attacker can easily use your private key by communicating with your local ssh-agent if both of you are on the compromised machines at the same time. Mitigation:

* inform the mechine's administration that your account on their machine may have be compromised

## scenario 2: no private key on compromised machines, access via ssh-agent without forwarding

Your ssh private key should not be compromised.