SSH-Agent unter Linux: Vermeiden Sie das erneute Eintippen Ihrer Passphrase, ohne Ihren Schlüssel unbeaufsichtigt herumliegen zu lassen.

Wenn Sie einen durch eine Passphrase geschützten SSH-Schlüssel verwenden, kennen Sie wahrscheinlich das Problem: Er ist zwar sicher, aber es wird schnell lästig, wenn Sie die Passphrase jedes Mal neu eingeben müssen, wenn Sie sich verbinden oder… Git PullDie falsche Antwort ist, die Passphrase vom Schlüssel zu entfernen. Die beste Antwort ist in vielen Fällen: ssh-Agent.

ssh-Agent Der entsperrte Schlüssel wird für Ihre Sitzung im Speicher gehalten. Sie geben die Passphrase einmal ein, anschließend beantwortet der Agent SSH-Anfragen. Das ist praktisch, erfordert aber zwei Vorsichtsmaßnahmen: Prüfen Sie, welcher Agent verwendet wird, und begrenzen Sie die Sitzungsdauer bei der Arbeit auf einem gemeinsam genutzten Rechner oder einem Administrationsserver.

Prüfen Sie, ob ssh-agent bereits ausgeführt wird.

Auf vielen Linux-Distributionen mit grafischer Oberfläche läuft bereits ein SSH-Agent. Bei reinem SSH, auf einem Server oder in einer minimalen Sitzung ist dies nicht immer der Fall. Überprüfen Sie zunächst die von den SSH-Tools verwendete Umgebungsvariable:

echo "$SSH_AUTH_SOCK"

Wenn die Ausgabe leer ist, weiß Ihre Shell nicht, mit welchem ​​Agenten sie kommunizieren soll. Sie können auch die bereits geladenen Schlüssel überprüfen:

ssh-add -l

Wenn Sie eine Nachricht erhalten wie Der Agent hat keine Identitäten.Der Agent antwortet korrekt, aber es wurde kein Schlüssel geladen. Wenn der Befehl meldet, dass keine Verbindung zum Agenten hergestellt werden kann, müssen Sie einen starten.

Starten Sie ssh-agent in Ihrer Sitzung

Um einen Agenten in der aktuellen Shell zu starten, verwenden Sie:

eval "$(ssh-agent -s)"

Der Befehl definiert die notwendigen Variablen, einschließlich SSH_AUTH_SOCK Und SSH_AGENT_PID. Ohne die evaluDer Agent kann zwar starten, aber Ihre Shell kann seine Umgebung nicht korrekt abrufen. Solche Details kosten Zeit, wenn man zu schnell testet.

Sie können dies direkt im Anschluss bestätigen:

echo "$SSH_AUTH_SOCK"

Auf einem persönlichen Rechner reicht das oft aus. Auf einem gemeinsam genutzten Server vermeide ich es jedoch, einen Agenten den ganzen Tag ohne Zeitlimit geöffnet zu lassen.

Fügen Sie einen SSH-Schlüssel mit begrenzter Lebensdauer hinzu

ssh-add ~/.ssh/id_ed25519

Sie geben die Passphrase einmal ein. Danach werden Verbindungen mit diesem Schlüssel über den Agenten geleitet. So prüfen Sie, was geladen ist:

ssh-add -l -E sha256

Um die Lebensdauer des Schlüssels im Agenten zu begrenzen, verwenden Sie -TBeispiel mit einer Stunde:

ssh-add -t 1h ~/.ssh/id_ed25519

Dies ist meine bevorzugte Einstellung auf einer administrativen Workstation. Sie behalten den Komfort des Agenten, aber der Schlüssel bleibt nicht unbegrenzt verfügbar, wenn Sie vergessen, sich abzumelden.

Testen einer Verbindung ohne erneute Eingabe des Passphrases

Sobald der Schlüssel geladen ist, testen Sie eine normale Verbindung:

ssh user@server

Wenn der Schlüssel mit dem Server übereinstimmt, fragt SSH nicht erneut nach der Passphrase. Falls dies fehlschlägt, versuchen Sie es erneut im ausführlichen Modus:

ssh -v user@server

Sie sehen, welcher Schlüssel angeboten wird, ob der Agent antwortet und wo die Verbindung blockiert wird. Falls das Problem eher beim serverseitigen SSH-Dienst liegt, habe ich auch dazu eine Anleitung veröffentlicht. SSH unter Ubuntu sauber neu starten und noch einer für Installieren Sie SSH neu, wenn es nicht mehr reagiert..

Entfernen Sie die Schlüssel vom Agenten.

So entfernen Sie einen bestimmten Schlüssel:

ssh-add -d ~/.ssh/id_ed25519

Alle geladenen Schlüssel löschen:

ssh-add -D

Wenn Sie den Agenten manuell gestartet haben und ihn stoppen möchten:

ssh-agent -k

Verwechseln Sie diese Befehle nicht mit dem Löschen der Schlüsseldatei in ~/.sshHier entfernen Sie lediglich den Schlüssel aus dem Speicher des Agenten.

Seien Sie vorsichtig beim Übertragen von SSH-Agenten.

Agententransfer, oft aktiviert mit ssh -ADadurch kann ein entfernter Rechner Ihren lokalen Agenten verwenden, um den Datenverkehr an einen anderen Server umzuleiten. Das ist in manchen Umgebungen nützlich, ich würde es aber standardmäßig vermeiden.

Wird der Zwischenserver kompromittiert, wird Ihr privater Schlüssel zwar nicht kopiert, der Agent ist aber weiterhin erreichbar, solange die Sitzung besteht. Für einen Bastion-Host oder einen Rechner, den Sie nicht vollständig kontrollieren, empfiehlt sich ein dedizierter Schlüssel, eine begrenzte Gültigkeitsdauer oder eine restriktivere SSH-Konfiguration.

Um eine lange Sitzung aufrechtzuerhalten, ohne Ihre Arbeit zu verlieren, Bildschirm unter Linux Erfüllt ein weiteres Bedürfnis: die Aufrechterhaltung einer offenen Administratorsitzung auf Serverseite. Dies ist kein Ersatz für ssh-AgentDie beiden Werkzeuge ergänzen sich jedoch gut.

Den Kompromiss, den ich beibehalten würde

Entfernen Sie die Passphrase nicht von Ihren SSH-Schlüsseln, um ein paar Sekunden zu sparen. Laden Sie stattdessen den Schlüssel in ssh-AgentÜberprüfen Sie die aktiven Tasten mit ssh-add -lbegrenzen Sie die Dauer mit ssh-add -t Wenn der Kontext sensibel ist, sollte der Agent am Ende der Intervention geleert werden.

Die Handbuchseiten von ssh-Agent, ssh-add Und ssh Sie beschreiben detailliert die verfügbaren Optionen. Man muss sich nicht alles merken. Wichtig ist, einen sicheren Schlüssel zu haben, der aber auch verwendet werden kann, ohne dass jede Verbindung zur lästigen Pflicht wird.

sudo apt update && sudo apt upgrade