ssh-add dauerhaft speichern

[Steffen Grau]

Hi,
irgendwie muss ich nach jedem Neustart wieder ssh-add /wo/auch/immer/schluessel.ssh ausführen anstatt, dass das dauerhaft gespeichert wird :-/
Einen Parameter zur dauerhaften Speicherung konnte ich in der Anleitung ssh-add Anleitung leider nicht finden und ohne Putty's netter GUI ist mir jetzt auch nicht bekannt, wo ich das bei einem Linux System als 'permanent key' hinterlege.
Thx

[Matti Maekitalo]

Tach auch.

irgendwie muss ich nach jedem Neustart wieder ssh-add /wo/auch/immer/schluessel.ssh ausführen anstatt, dass das dauerhaft gespeichert wird :-/
Einen Parameter zur dauerhaften Speicherung konnte ich in der Anleitung ssh-add Anleitung leider nicht finden und ohne Putty's netter GUI ist mir jetzt auch nicht bekannt, wo ich das bei einem Linux System als 'permanent key' hinterlege.

Alle relevanten Einstellungen des SSH Clients legt man üblicherweise nach $HOME/.ssh, der private Schlüssel kommt da hin (z.B. $HOME/.ssh/id_rsa).

Bis die Tage,
Matti

[fastix®]

Moin!

Alle relevanten Einstellungen des SSH Clients legt man üblicherweise nach $HOME/.ssh, der private Schlüssel kommt da hin (z.B. $HOME/.ssh/id_rsa).

... was sich auch /etc/ssh/ssh_config nachlesen oder (wenn man genau weiß warum) für alle Benutzer ändern lässt.

MFFG (Mit freundlich- friedfertigem Grinsen)

fastix

[Tom]

Hello,

Alle relevanten Einstellungen des SSH Clients legt man üblicherweise nach $HOME/.ssh, der private Schlüssel kommt da hin (z.B. $HOME/.ssh/id_rsa).

... was sich auch /etc/ssh/ssh_config nachlesen oder (wenn man genau weiß warum) für alle Benutzer ändern lässt.

Interessant anzumerken wäre noch, dass der Zugang über Schlüssel erhalten bleibt, wenn man das Konto des Users für Login sperrt (nicht: löscht).

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[Christian Seiler]

Hallo Tom,

... was sich auch /etc/ssh/ssh_config nachlesen oder (wenn man genau weiß warum) für alle Benutzer ändern lässt.

Interessant anzumerken wäre noch, dass der Zugang über Schlüssel erhalten bleibt, wenn man das Konto des Users für Login sperrt (nicht: löscht).

Nicht unbedingt, das hängt von der Serverkonfiguration ab bzw. wie der User "gesperrt" wurde. UsePAM yes in der sshd_config und die korrekten PAM-Module können auch einen Key-Login verhindern.

Viele Grüße,
Christian

[Tom]

Hello Christian,

... was sich auch /etc/ssh/ssh_config nachlesen oder (wenn man genau weiß warum) für alle Benutzer ändern lässt.

Interessant anzumerken wäre noch, dass der Zugang über Schlüssel erhalten bleibt, wenn man das Konto des Users für Login sperrt (nicht: löscht).

Nicht unbedingt, das hängt von der Serverkonfiguration ab bzw. wie der User "gesperrt" wurde. UsePAM yes in der sshd_config und die korrekten PAM-Module können auch einen Key-Login verhindern.

Danke für den Hinweis.
Das möchte ich auf jeden Fall nochmal näher untersuchen.
Wenn man dadurch sicher "Schlüssellöcher" vermeiden könnte, wäre das doch sehr wünschenswert!
Bisher habe ich es leider immer nur anders herum erlebt.

Liebe Grüße aus dem schönen Oberharz

Tom vom Berg

[dedlfix]

Hi!

Vorab, ich hab da auch keine Lösung und von ssh-add höre ich grad zum ersten Mal.

irgendwie muss ich nach jedem Neustart wieder ssh-add /wo/auch/immer/schluessel.ssh ausführen anstatt, dass das dauerhaft gespeichert wird :-/
Einen Parameter zur dauerhaften Speicherung konnte ich in der Anleitung ssh-add Anleitung leider nicht finden

ssh-add verweist ja auf ssh-agent und in beiden man-Pages konnte ich auch nichts finden, dass da irgendein Automatismus vorgesehen ist. Lediglich die Datei kann man weglassen, dann wird beim ssh-add die Datei ~/.ssh/identity verwendet.

und ohne Putty's netter GUI ist mir jetzt auch nicht bekannt, wo ich das bei einem Linux System als 'permanent key' hinterlege.

Was genau ist denn dein Ziel? Warum nimmst du den ssh-agent beziehungsweise was für einen Vorteil versprichst du dir dadurch? Reicht es für ein Schlüssel-Login nicht, deinen öffentlichen Schlüssel am Zielsystem zu hinterlegen?

Lo!

[Christian Seiler]

Hallo,

irgendwie muss ich nach jedem Neustart wieder ssh-add /wo/auch/immer/schluessel.ssh ausführen anstatt, dass das dauerhaft gespeichert wird :-/
Einen Parameter zur dauerhaften Speicherung konnte ich in der Anleitung ssh-add Anleitung leider nicht finden und ohne Putty's netter GUI ist mir jetzt auch nicht bekannt, wo ich das bei einem Linux System als 'permanent key' hinterlege.

Naja, die Idee ist eigentlich die folgende: Man will den SSH-Key nicht unverschlüsselt auf der Platte liegen lassen, weil der sich ja zum Login direkt eignet, d.h. wenn jemand anderes einfach mal so ein Backup o.ä. in die Hände bekommt, dann hat diese Person dann sofort Vollzugriff auf alles, was der Key freischaltet.

Wenn man aber den Key nun mit einem Passwort schützt, dann hat das zur Folge, dass bei jeder SSH-Sitzung das Passwort des Keys abgefragt wird. Das will man natürlich auch wieder nicht, weil Keys ja gerade Passwörter ersetzen sollen.

Daher gibt's einen Kompromiss: ssh-agent, ein Programm, welches im Hintergrud läuft. Dieses Programm merkt sich den Key solange es läuft (oder nur für eine bestimmte Zeit, kann man einstellen, je nach Paranoia-Level) - dafür braucht man dann aber ssh-add, um den Key zum Agent (einmalig) hinzuzufügen. Jedes Mal, wenn nun SSH eine Verbindung aufbaut, fragt es den Agent nach dem Key und der gibt den dann raus [1] und die Verbindung klappt ohne nochmaliges Eingeben des Passworts.

Wenn Du Dir nun sagst: Mir ist egal, dass der Key unverschlüsselt auf der Festplatte rumliegt und wenn jemand irgendwie an die Datei rankommt, dann halt Pech für mich, dann kannst Du auch das Passwort des SSH-Keys entfernen. Das geht mit folgendem Befehl:

ssh-keygen -p

Damit änderst Du das Passwort des Keys (erst wirst Du 1x nach dem alten Passwort gefragt und dann 2x nach dem neuen) - und wenn Du das neue Passwort leer lässt, wird der Key unverschlüsselt gespeichert. Damit musst Du dann in Zukunft kein Passwort mehr eingeben für den Key. In meinen Augen ist das NICHT ZU EMPFEHLEN, aber das musst Du selbst wissen.

Hinweis: Der SSH-Agent bietet noch weitere Vorteile, nämlich das sogenannte Agent-Forwarding. Damit kann der Agent auf der SSH-Kiste, auf der man sich einloggt einen "Sub-Agent" starten, [2] der dann für weitere SSH-Prozesse auf dem entfernten Server so tut, als ob da Dein lokaler Agent liefe. Damit kannst Du Dich dann von den Rechnern aus auf weiteren anderen Rechnern einloggen, ohne wieder ein Passwort eingeben zu müssen. [3] Wenn Du beschließt, auf ssh-add zu verzichten, dann funktioniert natürlich das Agent-Forwarding nicht mehr. Du kannst aber selbst mit einem unverschlüsselten Key den Agent verwenden - indem Du einfach ssh-add verwendest, was dann aber nicht mehr nach einem Passwort fragt.

Viele Grüße,
Christian

[1] Strenggenommen gibt der Agent den aus Sicherheitsgründen nicht heraus sondern führt die Krypto-Operation, wofür der Key nötig ist, selbst durch.

[2] Strenggenommen mancht das SSH selbst.

[3] Muss explizit in der Config oder über die Kommandozeilenoption "-A" aktiviert sein, sollte man außerdem nur machen mit SSH-Severn, denen man vertraut.