Kürzlich habe ich meinem Autostart (in KDE) das folgende Skript hinzugefügt:
eval `ssh-agent`
ssh-add
Das Skript sollte beim Anmelden gestartet werden und nach meiner Passphrase fragen und meinen geheimen Schlüssel laden. Das funktioniert fast einwandfrei. Das Skript wird richtig ausgeführt, der Agent wird gestartet, die Umgebungsvariablen sind alle festgelegt und ich werde nach meiner Passphrase gefragt. Das einzige Problem ist, dass der Schlüssel danach nicht geladen wird. Aber wenn ich dann ssh-add in ein Terminal eingebe, werde ich nach meiner Passphrase gefragt und der Schlüssel wird für den Rest meiner X-Sitzung gespeichert.
Was mache ich falsch? Warum wird der Schlüssel nicht geladen, obwohl ich nach meiner Passphrase gefragt werde?
PS: Ich verwende Debian Jessie.
Antwort1
Ich kann mir zwei mögliche Szenarien vorstellen, die dies verursachen könnten.
Beides ist darauf zurückzuführen, dass viele Desktop-Manager ihren eigenen SSH-Schlüsselagenten starten. Dies geschieht, weil der Agent vor dem Desktop-Manager gestartet werden muss, damit die exportierten Variablen von Anwendungen abgerufen werden können, die vom Desktop-Manager (Ihrem Terminalemulator) gestartet werden.
Ihr Desktop-Manager startet seinen eigenen SSH-Agenten, nachdem Sie Ihren gestartet haben, und ersetzt ihn letztendlich.
Ich bin nicht sicher, an welchem Punkt oder wie Sie Ihren SSH-Agenten starten, aber wenn der Desktop-Manager einen nach Ihrem startet, überschreiben seine exportierten Variablen die von Ihnen erstellten.
Ihr Desktop-Manager startet seinen eigenen SSH-Agenten vor Ihrem und Ihrer wird nicht gespeichert.
Wenn Sie nur ein Terminalfenster öffnen und Folgendes tun
eval $(ssh-agent); ssh-add, bleiben die dabei exportierten Variablenssh-agentnach dem Schließen des Terminalfensters nicht erhalten. Sobald Sie ein neues Terminalfenster öffnen, erhalten Sie die Variablen, die vom SSH-Agenten festgelegt wurden, der vom Desktop-Manager gestartet wurde.
Es ssh-agentfunktioniert so, dass im Hintergrund ein Daemon gestartet wird, der dann mehrere Variablen ausgibt, die eingerichtet werden müssen.
$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-JLbBwVBP4754/agent.4754; export SSH_AUTH_SOCK;
SSH_AGENT_PID=4755; export SSH_AGENT_PID;
echo Agent pid 4755;
Wenn Sie also eval $(ssh-agent), legen Sie einfach alle diese Variablen fest.
Variablen werden jetzt nur von untergeordneten Elementen geerbt. Damit sie in Ihrem Desktop-Manager bestehen bleiben, müssen sie vor dem Start Ihres Desktop-Managers festgelegt werden. Dies kann schwierig zu bewerkstelligen sein und ist von Distribution zu Distribution unterschiedlich. Aus diesem Grund machen es viele Desktop-Manager selbst.
Beachten Sie, dass dies manchmal auch während der Initialisierung des PAM-Stacks geschieht.
Antwort2
Wie Patrick anmerkt, ssh-agentkonkurriert Ihr Agent wahrscheinlich mit einer Instanz, die von Ihrer Desktop-Umgebung erzeugt wurde. Nun, „konkurrieren“ ist wahrscheinlich nicht das richtige Wort – die Variablen, die es anderen Anwendungen ermöglichen, mit dem Agenten zu kommunizieren, müssen sich in ihrer Umgebung befinden. Da alle Anwendungen in Ihrer Desktop-Sitzung auf irgendeine Weise von einem Teil der Desktop-Umgebung erzeugt werden (nehmen wir an, es ist der Sitzungsmanager), müssen Sie die Variablen zuerst in die Umgebungsliste des Sitzungsmanagers aufnehmen. Dies kann auf zwei Arten geschehen:
der Sitzungsmanager führt dies intern aus (abhängig von einer Option, die Sie irgendwo festlegen). Dies würde beinhalten, dass der Agent von einem PAM-Modul (aufgerufen vom Login/Sitzungsmanager) erzeugt wird.
durch ein Benutzerskript wie Ihres. Dies ist jedoch nicht so einfach, wie es scheint. Wenn der Sitzungsmanager Ihr Skript ausführt, erstellt er einen neuen Prozess – den Skriptinterpreter. In seiner Umgebung werden die Variablen festgelegt, können aber nicht einfach in den Sitzungsmanager – seinen übergeordneten Prozess – zurück exportiert werden. Dies entspricht dem Ausführen desselben in Ihrer Shell – das Ausführen des Skripts hat keinerlei Auswirkungen auf die Umgebung der aktuellen Shell. Sie müssten es tun
source– dann würden die Befehle von der aktuellen Shell ausgeführt, wodurch Sie Zugriff auf die aktualisierten/erstellten Variablen erhalten. Dies wäre im Sitzungsmanager ziemlich kompliziert (da es sich nicht um einen Shell-Interpreter handelt). Daherssh-agentist Ihr Skript nicht wirklich konkurrenzfähig. Es sitzt einfach da mit Identitäten, die von Ihrem Skript geladen wurden,ssh-addund niemand weiß wirklich davon.
Um eine Vorstellung davon zu bekommen, was vor sich geht, überprüfen Sie die Ausgabe von 1
ps fax | grep -E "(ssh|gpg)-[a]gent"
und ändern Sie Ihr Skript in
echo "SSH_AUTH_SOCK=$SSH_AUTH_SOCK" > ~/ssh-agent.stdout
echo "SSH_AGENT_PID=$SSH_AGENT_PID" >> ~/ssh-agent.stdout
eval `ssh-agent | tee -a ~/ssh-agent.stdout`
Dadurch wird der Inhalt der Variablen in die Datei gedruckt ~/ssh-agent.stdoutund die Ausgabe von an genau dieser Stelle hinzugefügt, ssh-agentbevor sie verarbeitet wird (und somit die Variablen exportiert werden). Vergleichen Sie den Inhalt der Datei mit den Umgebungsvariablen SSH_AUTH_SOCKund SSH_AGENT_PIDbeispielsweise in einem frisch erstellten Shell-Terminal. In den meisten Fällen können Sie feststellen, welches zuerst gestartet wurde, da die PIDs (zyklisch) monoton wachsen. Der gpg-agentTeil ist vorhanden, weil einige DEs die Möglichkeit nutzen, gpg-agentauch SSH-Agent-Dienste bereitzustellen.
Sie können diesen Zeilenaufruf auch ssh-agentvollständig entfernen. Wenn Ihr Skript ausgeführt wird, nachdem der SSH-Agent Ihre Desktopumgebung erstellt hat, wird Ihnen der Kennwortdialog angezeigt (übrigens für den richtigen Agenten), da die Umgebungsvariablen vorhanden sind. Wenn nicht, bedeutet dies, dass Ihr Skript vor der Agenteninstanz der DE ausgeführt wird und daher überhaupt keinen Zugriff auf einen Agenten hat.
1 die Klammern sind einenetter Trickgrepum sich selbst aus der Prozessliste zu entfernen .