Pracuji hlavně na mac a ssh/tmux se připojuji k linuxovému stroji, abych dělal svou práci. Mám ssh-agent spuštěný na počítači Linux. Mám
set -g update-environment "SSH_AUTH_SOCK SSH_ASKPASS WINDOWID SSH_CONNECTION XAUTHORITY"
v mém .tmux.conf . Přesto, kdykoli se znovu připojím k této relaci, musím spustit
tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK
aby nová okna tmux měla $SSH_AUTH_SOCK nastavit správně. Raději bych to nemusel dělat. Nějaké nápady?
Aktualizovat
Myslím, že to nevysvětluji dobře. Zde je moje funkce shellu pro otevření shellu na vzdáleném počítači:
sshh () {
tmux -u neww -n ${host} "ssh -Xt ${host} $*"
}
Když tmux spustí tento příkaz ssh, $SSH_AUTH_SOCK není nastavit, i když je zasazené do mého místního prostředí. Pokud to vložím do prostředí tmux s setenv příkaz výše, vše funguje dobře. Moje otázka zní, proč vůbec musím spouštět příkaz setenv?
Aktualizace 2
Více informací:
Když se připojím k existující relaci, $SSH_AUTH_SOCK není nastaven v prostředí tmux (nebo globálním prostředí).
% tmux showenv | grep -i auth_sock
-SSH_AUTH_SOCK
Pokud to nastavím ručně, věci fungují:
% tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK
Pokud odpojím a znovu připojím, $SSH_AUTH_SOCK se vrátí do stavu, kdy není nastaveno.
Přijatá odpověď:
Vzhledem k tomu, že jsem obdržel Bounty, znovu zveřejním svůj klíčový komentář pro úplnost – a abych nenavedl návštěvníky se stejným problémem na špatnou cestu:
Tmux odstraní proměnné prostředí
Manuální stránka Tmux uvádí, že update-environment odstraní proměnné „které ve zdrojovém prostředí neexistují […], jako by příkazu set-environment bylo dáno -r“.
Zřejmě to způsobilo problém. Podívejte se na Chrisovu odpověď níže. Stále si však nedokážu představit, jak by proměnná mohla chybět ve „zdrojovém prostředí“ a přitom být platná v nově vytvořeném okně tmux…
Předchozí odpověď:
Jak funguje přesměrování SSH
Na vzdáleném počítači se po navázání připojení SSH podívejte na prostředí vašeho shellu:
[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
Důležitý je zde SSH_AUTH_SOCK, který je aktuálně nastaven na nějaký soubor v /tmp. Pokud tento soubor prozkoumáte, uvidíte, že se jedná o zásuvku domény Unix – a je připojen ke konkrétní instanci ssh, ke které jste se připojili. Důležité je, že se to změní při každém připojení.
Jakmile se odhlásíte, tento konkrétní soketový soubor je pryč. Nyní, když půjdete a znovu připojíte svou relaci tmux, uvidíte problém. Má prostředí z doby, kdy byl tmux původně spuštěn – což mohlo být před týdny. Ten konkrétní socket je dávno mrtvý.
Související:Shell test, zda víceřádkový řetězec obsahuje zadaný vzor v posledním řádku?Řešení
Protože víme, že problém souvisí s tím, kde je aktuálně aktivní ověřovací soket SSH, umístěme jej na předvídatelné místo!
Do souboru .bashrc nebo .zshrc na vzdáleném počítači přidejte následující:
# 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
Nemyslím si, že byste do svého tmux.conf ani nemuseli vkládat příkaz „update-environment“. Podle manuálové stránky je SSH_AUTH_SOCK již ve výchozím nastavení pokryto.
Kredit
Moje odpověď je výňatek z tohoto blogového příspěvku od Marka ‚xb95‘ Smitha, který vysvětluje stejný problém pro obrazovku.