SSH-Agent wird nicht eingerichtet (SSH_AUTH_SOCK, SSH_AGENT_PID-Umgebungsvariablen nicht festgelegt)

Ich habe auf Kubuntu 12.04 ein neues Benutzerkonto für einen Freund eingerichtet. Wenn er benutzt ssh, bekommt er diesen Fehler:

Es konnte keine Verbindung zu Ihrem Authentifizierungsagenten hergestellt werden

Wir führen ssheinige Bash-Skripte aus.

Nachdem ich mir die Vielzahl von Dingen angesehen habe, die zu diesem Fehler führen können, bin ich auf diese Lösung gestoßen:

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

Dann kann er das laufen lassen ssh Befehle (und Bash-Skripte) wie erwartet ausführen.

Vor dem Ausführen dieser beiden Befehle werden die env-Variablen nicht in einem Terminal festgelegt:

$ echo $SSH_AGENT_PID

$ echo $SSH_AUTH_SOCK

$ 

Nach dem Ausführen der Befehle werden die Umgebungsvariablen wie erwartet festgelegt. Sie bleiben jedoch nicht gesetzt (z. B. in einer anderen Shell oder nach einem Neustart).

Ich möchte wissen, wie man seinen Computer einrichtet, damit er diese beiden Befehle nicht ausführen muss, um die env-Variablen einzustellen. Ich muss sie nicht (jemals) auf meinem Computer ausführen. Bisher sehe ich keinen Unterschied zwischen unseren Maschinen.

Ich sehe diese Information in der Manpage, aber sie sagt mir nicht, wie Ubuntu den Agenten normalerweise automatisch einrichtet oder was auf dem Computer meines Freundes geschieht, so dass dies für ihn nicht funktioniert.

Es gibt zwei Möglichkeiten, einen Agenten einzurichten: Die erste besteht darin, dass der Agent einen neuen Unterbefehl startet, in den einige Umgebungsvariablen exportiert werden, z. B. ssh-agent xterm &. Zum anderen druckt der Agent die erforderlichen Shell-Befehle (entweder sh (1) oder csh (1) Syntax kann generiert werden), die in der aufrufenden Shell ausgewertet werden können, z. B. eval ssh-agent -sfür Bourne-Shells wie sh (1) oder ksh (1) und evalssh-agent -c für csh (1) und Derivate.

Nach der Installation acctund dem Neustart ist dies die Ausgabe von lastcomm:

ssh-agent         F    newuser __         0.12 secs Wed Aug  7 11:02
ssh-agent         F    newuser __         0.00 secs Wed Aug  7 20:34
ssh-agent         F    newuser __         0.02 secs Wed Aug  7 20:02
ssh-agent         F    newuser __         0.01 secs Thu Aug  8 12:39
ssh-agent         F    newuser __         0.02 secs Thu Aug  8 07:45

Von der Manpage:

F - Befehl wird nach einem Fork ausgeführt, jedoch ohne folgenden Exec

Ich bin mir nicht sicher, ob das von Bedeutung ist.

Sie haben erwähnt, dass Ihr Benutzer sshangemeldet ist und sich nicht lokal anmeldet. Also die use-ssh-agentin/etc/X11/Xsession.options einer falschen Fährte: Es wird nicht auf SSH - Sitzungen ausgeführt wird, nur wenn sie in einen X11 GUI Desktop lokal (oder mit einiger virtuellen X11 - Sitzung wie über VNC oder RDP) anzumelden.

Überprüfen Sie stattdessen, ob libpam-sshauf einem der beiden Systeme installiert ist. Es kann so konfiguriert werden, dass ein Benutzer mithilfe von Passphrasen für private SSH-Schlüssel authentifiziert wird. Dies ist jedoch optional und Sie müssen den Schlüssel speziell dafür platzieren~/.ssh/login-keys.d/ für diese Funktionalität platzieren.

Die andere Funktion besteht jedoch darin, einen SSH-Agenten bei jeder Anmeldesitzung automatisch zu starten und dem Agenten automatisch private SSH-Schlüssel hinzuzufügen, wenn deren Passphrase mit dem Anmeldekennwort des Benutzers übereinstimmt. Ich denke, dies könnte die Ursache für das unterschiedliche Verhalten Ihrer Systeme sein.

Für die

$ eval `ssh-agent -s`

Konstruieren Sie, um zu funktionieren, wenn Sie ein „Startskript“ einfügen. Ihre Sitzung und letztendlich das Terminal, auf dem Sie die Umgebung erwarten, müssen Nachkommen (von forkund exec) dieses Skripts sein. Der Grund dafür ist, dass die Ausgabe von ssh-agent -sbei der Auswertung Umgebungsvariablen im Shell-Aufruf festlegteval . Dort können sie weitergegeben werden und auch unterwegs verloren gehen.

Wenn ssh-agentalso das Skript A während der Anmeldung ausgeführt wird, aber das Terminal B, in dem Sie das Shell-Skript starten, kein Nachkomme von A ist, können Sie die Umgebung in B nicht sehen.

Wenn Sie zufällig ssh-agentals systemd --userDienst gestartet wurden, müssen Sie möglicherweise stattdessen die Konvention verwenden: Geben Sie ssh-agent die Variablen nicht an, sondern verwenden Sie die allgemeinen Kenntnisse beim Starten des Agenten und beim Starten der Sitzung. ZB ~/.config/systemd/user/ssh-agent.servicesieht mein so aus:

[Unit]
Description=SSH agent

[Service]
Type=simple
Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket
ExecStart=/usr/bin/ssh-agent -D -a $SSH_AUTH_SOCK

[Install]
WantedBy=default.target

Und in meinem habe ~/.profileich die Leitung

export SSH_AUTH_SOCK="${XDG_RUNTIME_DIR}/ssh-agent.socket"

Beachten Sie, dass %tim ersteren ${XDG_RUNTIME_DIR}im letzteren entspricht.

Hinweis: Das freut mich nicht!

Ich habe die Antwort hier gefunden:

http://www.bernatchez.net/userauth.html

Unter Ubuntu kann das Dienstprogramm ssh-add keine Zertifikatdateien laden. Es tritt auf, wenn der Agent derjenige ist, der durch gnome-keyring implementiert wurde. Die Lösung besteht darin, die Verwendung der ssh-Komponente von gnome-keyring zu beenden. Da der Initialisierungsprozess tatsächlich einen echten ssh-Agenten startet und dann gnome-keyring-ssh.desktop startet, der AUTH_SOCKET blockiert, um ihn zu übernehmen, können wir zum ursprünglichen ssh-Agenten zurückkehren, indem wir gnome-keyring-ssh.desktop deaktivieren.

Gnome-keyring-ssh.desktop deaktivieren:

cd /etc/xdg/autostart/
sudo emacs gnome-keyring-ssh.desktop

Fügen Sie der Desktop-Datei die folgende Zeile hinzu, speichern Sie sie und starten Sie sie neu:

X-GNOME-Autostart-enabled=false

Sie haben das erwähnt

$ eval `ssh-agent -s`
$ ssh-add ~/.ssh/some_id_rsa

funktioniert wie gewünscht. Sie brauchen diese also nur zur richtigen Zeit auszuführen, entweder in .bash_profile oder .xsession. Fügen Sie Debug-Anweisungen hinzu (date; env|sort) >> /tmp/log, um zu verstehen, wann sie ausgeführt werden.