Ich arbeite hauptsächlich auf einem Mac und ssh/tmux hänge mich an einen Linux-Rechner an, um meine Arbeit zu erledigen. Ich habe ssh-agent auf dem Linux-Rechner ausgeführt. Ich habe
set -g update-environment "SSH_AUTH_SOCK SSH_ASKPASS WINDOWID SSH_CONNECTION XAUTHORITY"
in meiner .tmux.conf . Immer wenn ich mich jedoch wieder an diese Sitzung anhänge, muss ich rennen
tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK
damit neue tmux-Fenster $SSH_AUTH_SOCK haben richtig einstellen. Ich würde es vorziehen, dies nicht tun zu müssen. Irgendwelche Ideen?
Aktualisieren
Ich glaube, ich erkläre das nicht gut. Hier ist meine Shell-Funktion, um eine Shell auf einem entfernten Rechner zu öffnen:
sshh () {
tmux -u neww -n ${host} "ssh -Xt ${host} $*"
}
Wenn tmux diesen ssh-Befehl ausführt, $SSH_AUTH_SOCK ist nicht gesetzt, obwohl es ist in meiner lokalen Umgebung eingestellt. Wenn ich dies in die Umgebung von tmux mit der setenv Befehl oben, alles funktioniert gut. Meine Frage ist, warum muss ich den Befehl setenv überhaupt ausführen?
Aktualisierung 2
Weitere Informationen:
Wenn ich an eine bestehende Sitzung anhänge, $SSH_AUTH_SOCK ist nicht in der tmux-Umgebung (oder globalen Umgebung) festgelegt.
% tmux showenv | grep -i auth_sock
-SSH_AUTH_SOCK
Wenn ich es manuell einstelle, funktionieren die Dinge:
% tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK
Wenn ich abtrenne und wieder anhänge, $SSH_AUTH_SOCK wird wieder nicht gesetzt.
Akzeptierte Antwort:
Da ich die Prämie erhalten habe, poste ich meinen Schlüsselkommentar der Vollständigkeit halber erneut – und um Besucher mit demselben Problem nicht auf die falsche Spur zu bringen:
Tmux entfernt Umgebungsvariablen
Die Manpage von Tmux besagt, dass update-environment Variablen entfernt, „die in der Quellumgebung nicht existieren […], als ob -r an den Befehl set-environment übergeben wurde“.
Anscheinend hat das das Problem verursacht. Siehe die Antwort von Chris unten. Ich kann mir jedoch immer noch nicht vorstellen, wie die Variable in der „Quellumgebung“ fehlen und dennoch im neu erstellten tmux-Fenster gültig sein könnte…
Vorherige Antwort:
So funktioniert die SSH-Weiterleitung
Sehen Sie sich auf dem Remote-Rechner die Umgebung Ihrer Shell an, nachdem Sie die SSH-Verbindung hergestellt haben:
[email protected]:~$ env | grep SSH
SSH_CLIENT=68.38.123.35 45926 22
SSH_TTY=/dev/pts/0
SSH_CONNECTION=68.38.123.35 48926 10.1.35.23 22
SSH_AUTH_SOCK=/tmp/ssh-hRNwjA1342/agent.1342
Der wichtige hier ist SSH_AUTH_SOCK, der derzeit auf eine Datei in /tmp eingestellt ist. Wenn Sie diese Datei untersuchen, werden Sie feststellen, dass es sich um einen Unix-Domain-Socket handelt – und mit der bestimmten Instanz von ssh verbunden ist, mit der Sie sich verbunden haben. Wichtig ist, dass sich dies jedes Mal ändert, wenn Sie eine Verbindung herstellen.
Sobald Sie sich abmelden, ist diese bestimmte Socket-Datei verschwunden. Wenn Sie jetzt Ihre tmux-Sitzung erneut anhängen, werden Sie das Problem sehen. Es hat die Umgebung aus der Zeit, als tmux ursprünglich gestartet wurde – was vor Wochen hätte sein können. Dieser spezielle Socket ist schon lange tot.
Verwandt:Shell-Test, ob eine mehrzeilige Zeichenfolge in der letzten Zeile ein bestimmtes Muster enthält?Lösung
Da wir wissen, dass das Problem damit zu tun hat, zu wissen, wo sich der derzeit aktive SSH-Authentifizierungs-Socket befindet, platzieren wir ihn einfach an einer vorhersehbaren Stelle!
Fügen Sie in Ihrer .bashrc- oder .zshrc-Datei auf dem Remote-Computer Folgendes hinzu:
# Predictable SSH authentication socket location.
SOCK="/tmp/ssh-agent-$USER-screen"
if test $SSH_AUTH_SOCK && [ $SSH_AUTH_SOCK != $SOCK ]
then
rm -f /tmp/ssh-agent-$USER-screen
ln -sf $SSH_AUTH_SOCK $SOCK
export SSH_AUTH_SOCK=$SOCK
fi
Ich glaube nicht, dass Sie in Ihre tmux.conf einen ‚update-environment command‘ einfügen müssen. Laut Manpage ist SSH_AUTH_SOCK bereits standardmäßig abgedeckt.
Kredit
Meine Antwort ist ein Auszug aus diesem Blogbeitrag von Mark „xb95“ Smith, der das gleiche Problem für den Bildschirm erklärt.