Lavoro principalmente su un mac e mi collego ssh/tmux a una macchina Linux per fare il mio lavoro. Ho ssh-agent in esecuzione sulla macchina Linux. Ho
set -g update-environment "SSH_AUTH_SOCK SSH_ASKPASS WINDOWID SSH_CONNECTION XAUTHORITY"
nel mio .tmux.conf . Tuttavia, ogni volta che mi ricollego a questa sessione, devo correre
tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK
affinché le nuove finestre di tmux abbiano $SSH_AUTH_SOCK impostato correttamente. Preferirei non doverlo fare. Qualche idea?
Aggiorna
Penso di non essermi spiegato bene. Ecco la mia funzione shell per aprire una shell su una macchina remota:
sshh () {
tmux -u neww -n ${host} "ssh -Xt ${host} $*"
}
Quando tmux esegue questo comando ssh, $SSH_AUTH_SOCK è non impostato, anche se lo è ambientato nel mio ambiente locale. Se lo metto nell'ambiente di tmux con setenv comando sopra, tutto funziona bene. La mia domanda è:perché devo eseguire il comando setenv?
Aggiornamento 2
Maggiori informazioni:
Quando mi allego a una sessione esistente, $SSH_AUTH_SOCK non è impostato nell'ambiente tmux (o nell'ambiente globale).
% tmux showenv | grep -i auth_sock
-SSH_AUTH_SOCK
Se l'ho impostato manualmente, le cose funzionano:
% tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK
Se distacco e ricollego, $SSH_AUTH_SOCK torna a non essere impostato.
Risposta accettata:
Dal momento che ho ricevuto il Bounty, ripubblicherò il mio commento chiave per completezza e per evitare di indirizzare i visitatori con lo stesso problema sulla strada sbagliata:
Tmux rimuoverà le variabili d'ambiente
La pagina man di Tmux afferma che update-environment rimuoverà le variabili "che non esistono nell'ambiente di origine […] come se -r fosse stato dato al comando set-environment".
Apparentemente questo è ciò che ha causato il problema. Vedi la risposta di Chris di seguito. Tuttavia, non riesco ancora a immaginare come la variabile possa essere assente nell '"ambiente di origine" e tuttavia essere valida nella finestra tmux appena creata...
Risposta precedente:
Come funziona l'inoltro SSH
Sulla macchina remota, dai un'occhiata all'ambiente della tua shell dopo aver stabilito la connessione SSH:
[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
Quello importante qui è SSH_AUTH_SOCK che è attualmente impostato su un file in /tmp. Se esamini questo file, vedrai che è un socket di dominio Unix ed è connesso alla particolare istanza di ssh a cui ti sei connesso. È importante sottolineare che questo cambia ogni volta che ti connetti.
Non appena ci si disconnette, quel particolare file socket scompare. Ora, se vai e ricolleghi la tua sessione tmux, vedrai il problema. Ha l'ambiente di quando tmux è stato originariamente lanciato, che potrebbe essere stato settimane fa. Quella presa in particolare è morta da tempo.
Correlati:test della shell se la stringa di più righe contiene il modello specificato nell'ultima riga?Soluzione
Poiché sappiamo che il problema ha a che fare con il sapere dove si trova il socket di autenticazione SSH attualmente attivo, mettiamolo in un posto prevedibile!
Nel tuo file .bashrc o .zshrc sul computer remoto, aggiungi quanto segue:
# 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
Non penso che tu debba nemmeno inserire un "comando update-environment" nel tuo tmux.conf. Secondo la pagina man, SSH_AUTH_SOCK è già coperto per impostazione predefinita.
Credito
La mia risposta è un estratto di questo post del blog di Mark 'xb95' Smith che spiega lo stesso problema per lo schermo.