SSH-Passwort-Manager: SSH-Passwörter sicher speichern

Erst Schlüssel, dann Passwörter

Das beste SSH-Passwort ist das, das Sie nicht mehr brauchen. Mit einem Schlüssel prüft der Server eine Signatur, und kein Geheimnis geht über das Netzwerk, sodass ein Mitschnitt Ihrer Eingaben oder ein gefälschter Server nichts Brauchbares erhält. Erzeugen Sie einen Schlüssel und installieren Sie ihn auf dem Server:

ssh-keygen -t ed25519 -C "you@laptop"
ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

Testen Sie ihn und schalten Sie dann die Passwort-Anmeldung auf dem Server ab, wie in SSH-Passwort-Anmeldung deaktivieren beschrieben. Die vollständige Einrichtung des Schlüssels steht unter einen Ed25519-SSH-Schlüssel erzeugen.

Passwörter bleiben aus echten Gründen: Geräte, die nur Passwörter annehmen, Konten, die Sie nicht verwalten, sudo auf dem Server und die erste Anmeldung, bevor ein Schlüssel installiert ist. Genau diese müssen gut aufbewahrt werden.

Warum sshpass -p eine schlechte Idee ist

sshpass tippt ein Passwort für Sie in ssh. Die häufigste Form ist zugleich die schwächste:

sshpass -p 'S3cret!' ssh deploy@203.0.113.10

Das Passwort steht in der Kommandozeile. Solange der Befehl läuft, kann jeder Benutzer des Rechners es mit ps lesen, und es wird in der Shell-Historie gespeichert. Das eigene Handbuch nennt -p die unsicherste Option. Die beiden anderen Formen sind besser:

sshpass -f ~/.ssh/web.pass ssh deploy@203.0.113.10
SSHPASS='S3cret!' sshpass -e ssh deploy@203.0.113.10

-f liest die erste Zeile einer Datei, die nur Sie lesen dürfen (chmod 600). -e liest die Variable SSHPASS, die für Prozesse unter Ihrem Benutzer weiterhin sichtbar ist. Zwei weitere Fallen: sshpass kann die Frage nach dem Host-Schlüssel nicht beantworten, auf einem neuen Server bricht es daher mit Exit-Code 6 ab, und viele setzen dann StrictHostKeyChecking=no, was den Schutz vor einem gefälschten Server entfernt. Akzeptieren Sie den Host-Schlüssel stattdessen einmal von Hand.

Passwörter im Schlüsselbund des Systems ablegen

Statt einer Datei überlassen Sie das Passwort dem Betriebssystem. Auf dem Mac speichern Sie es im Anmelde-Schlüsselbund. Steht -w ohne Wert am Ende, fragt der Befehl nach dem Passwort, das so nie auf der Kommandozeile erscheint:

security add-generic-password -a deploy -s ssh-web -w

Lesen Sie es nur für den Befehl aus, der es braucht:

SSHPASS="$(security find-generic-password -a deploy -s ssh-web -w)" sshpass -e ssh deploy@web

Auf Linux-Desktops erledigt secret-tool dasselbe mit dem GNOME-Schlüsselbund oder KWallet:

secret-tool store --label='ssh web' service ssh host web user deploy
secret-tool lookup service ssh host web user deploy

Der Schlüsselbund wird bei der Anmeldung entsperrt und hält das Passwort verschlüsselt auf der Platte. Jedes Programm unter Ihrem Benutzer kann es trotzdem anfordern, deshalb bleibt die erste Antwort ein Schlüssel.

Passphrasen von Schlüsseln genauso ablegen

Ein Schlüssel sollte eine Passphrase haben, und der Schlüsselbund kann sie sich merken, damit Sie sie nur einmal eingeben. Auf dem Mac:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Host *
  UseKeychain yes
  AddKeysToAgent yes

Die Details, auch was nach einem Neustart passiert, stehen unter ssh-agent mit dem macOS-Schlüsselbund nutzen. Unter Linux übernimmt ssh-agent oder der Schlüsselbund des Desktops diese Rolle.

Was ein SSH-Passwort-Manager können sollte

Ein allgemeiner Passwort-Manager speichert das Geheimnis. Für SSH zählen ein paar Dinge mehr:

Verschlüsselung auf Ihrem Gerät, mit einem Passwort oder der Systementsperrung zum Öffnen. Synchronisiert er, darf der Server nur verschlüsselte Daten sehen. Der Leitfaden zum Ende-zu-Ende-verschlüsselten Vault listet die Fragen, die Sie stellen sollten.
Ein Login für viele Server. Ein Benutzer mit Passwort oder Schlüssel, einmal gespeichert und mit jedem Server verknüpft, damit eine Änderung an einer Stelle passiert.
Schlüssel und Passwörter zusammen, damit ein Server, der auf einen Schlüssel umsteigt, denselben Eintrag behält.
Eingabe nur auf Anfrage. Das Passwort geht an die Abfrage, die es verlangt, nicht in die Zwischenablage und nicht in eine Datei.

Ein SSH-Schlüsselmanager mit verschlüsseltem Vault deckt diese Punkte an einer Stelle ab, direkt neben den Servern.

Fehler, die Sie vermeiden sollten

Passwörter in Skripten oder in einem Repository. Sie landen in Backups, Logs und den Klonen anderer.
Passwörter in der Shell-Historie. In bash setzen Sie HISTCONTROL=ignorespace und beginnen den Befehl mit einem Leerzeichen, damit er nicht gespeichert wird. In zsh nutzen Sie setopt HIST_IGNORE_SPACE.
Ein gemeinsames root-Passwort für ein Team. Geben Sie jeder Person ein eigenes Konto und einen Schlüssel und nutzen Sie sudo.
Überall dasselbe Passwort. Ein einziges Leck öffnet dann jeden Server.
Passwörter in der Zwischenablage. Zwischenablage-Manager und synchronisierte Zwischenablagen behalten eine Kopie.

Fragen

Ist es sicher, SSH-Passwörter in einem Passwort-Manager zu speichern?

Ja, wenn der Manager seine Daten auf Ihrem Gerät verschlüsselt und zum Öffnen ein Passwort oder die Systementsperrung verlangt. Das ist viel sicherer als eine Textdatei, ein Skript oder eine Notiz. Ein Schlüssel bleibt besser als jedes gespeicherte Passwort.

Warum ist sshpass -p unsicher?

Das Passwort steht in der Kommandozeile, also kann jeder auf dem Rechner es mit ps sehen, solange der Befehl läuft, und es landet in der Shell-Historie. sshpass -e oder -f vermeiden beides.

Kann ich ein SSH-Passwort in ~/.ssh/config eintragen?

Nein. OpenSSH hat in seiner Konfigurationsdatei absichtlich keine Passwort-Option. Die Datei kann mit IdentityFile auf einen Schlüssel zeigen, und dessen Passphrase kann im Schlüsselbund des Systems liegen.

Soll ich dasselbe Passwort auf mehreren Servern nutzen?

Nein. Ein kompromittierter Server öffnet dann alle anderen. Wenn Sie Passwörter nutzen müssen, nehmen Sie pro Server ein eigenes und verwalten Sie sie in einem Manager.

Quellen

Mehr zu Verschlüsselte Vaults

Alle Anleitungen