Perché devo reimpostare env vars in tmux quando ricollego?

Lavoro principalmente su un mac e ssh / tmux attach su una macchina Linux per fare il mio lavoro. Ho ssh-agent in esecuzione sulla macchina Linux. io 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 siano state $SSH_AUTH_SOCKimpostate correttamente. Preferirei non doverlo fare. Qualche idea?

Aggiornare

Penso che non lo sto spiegando 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, non$SSH_AUTH_SOCK è impostato, anche se è impostato nel mio ambiente locale. Se lo metto nell'ambiente di tmux con il comando sopra, tutto funziona bene. La mia domanda è: perché devo eseguire il comando setenv?setenv

Aggiornamento 2

Maggiori informazioni:

Quando mi collego a una sessione esistente, $SSH_AUTH_SOCKnon è impostato nell'ambiente tmux (o ambiente globale).

% tmux showenv | grep -i auth_sock
-SSH_AUTH_SOCK

Se lo imposto manualmente, le cose funzionano:

% tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK

Se mi stacco e ricollego, $SSH_AUTH_SOCKtorna a non essere impostato.

Da quando ho ricevuto il Bounty, ripubblicherò il mio commento-chiave per completezza e per evitare di impostare i visitatori con lo stesso problema sulla strada sbagliata:

Tmux rimuoverà le variabili di ambiente

La pagina man di Tmux afferma che update-environment rimuoverà le variabili "che non esistono nell'ambiente di origine [...] come se -r fosse dato al comando set-environment".

Apparentemente 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

Sul computer remoto, dai un'occhiata all'ambiente della tua shell dopo aver stabilito la connessione SSH:

user@remote:~$ 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 alcuni file in / tmp. Se esaminate questo file, vedrete che è un socket di dominio Unix - ed è connesso alla particolare istanza di ssh in cui vi siete collegati. È importante sottolineare che questo cambia ogni volta che ti connetti.

Non appena ti disconnetti, quel particolare file socket scompare. Ora, se vai e ricolleghi la sessione di tmux, vedrai il problema. Ha l'ambiente a partire dal lancio di tmux, che avrebbe potuto essere settimane fa. Quel particolare socket è morto da tempo.

Soluzione

Dato che sappiamo che il problema ha a che fare con la conoscenza della posizione del 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 nemmeno che tu debba inserire un 'update-environment command' nel tuo tmux.conf. Secondo la pagina man , SSH_AUTH_SOCK è già coperto di default.

Credito

La mia risposta è un estratto di questo post del blog di Mark 'xb95' Smith che spiega lo stesso problema per lo schermo .

L'ho capito. Risposta breve, ho dovuto rimuovere SSH_AUTH_SOCKda update-environment. Dato che era in quella lista, il valore veniva spazzato via ogni volta che mi ricollegavo. Grazie a @djf per l'indizio. La parte saliente della pagina man tmux (1) nella update-environmentsezione:

Tutte le variabili che non esistono nell'ambiente di origine sono impostate per essere rimosse dall'ambiente di sessione (come se -r fosse stato dato al comando set-environment).

Invece di usare tmux per gestire il mio agente ssh, ho bash gestirlo con:

### SSH Agent ### {{{
SSH_ENV="$HOME/.ssh/environment"

function start_agent {
    echo "Initialising new SSH agent..."
    /usr/bin/ssh-agent | sed 's/^echo/#echo/' > "${SSH_ENV}"
    echo succeeded
    chmod 600 "${SSH_ENV}"
    . "${SSH_ENV}" > /dev/null
    /usr/bin/ssh-add;
}

## Source SSH settings, if applicable
if [ -f "${SSH_ENV}" ]; then
    . "${SSH_ENV}" > /dev/null
    ps -ef | grep ${SSH_AGENT_PID} | grep ssh-agent$ > /dev/null || {
        start_agent;
    }
  else
    start_agent;
fi
### End SSH Agent ### }}}

Ho questo nel mio ~ / bashrc , e funziona benissimo.

Ho risposto a una domanda simile su StackOverflow https://stackoverflow.com/a/49395839/241025 . Dato che questa pagina è apparsa per prima nelle mie ricerche su Google, volevo pubblicare una versione di riepilogo qui.

Per ottenere che ogni sessione di tmux abbia un set di variabili d'ambiente personalizzate, è necessario aggiungere i valori alle variabili d'ambiente per sessione di tmux. Ecco un esempio di come farlo.

tmux new-session -s one
tmux setenv FOO foo-one
export FOO='foo-one'

È necessario l'ultimo passaggio dell'esportazione esplicita di FOO in modo che il riquadro corrente rilevi la variabile di ambiente. Eventuali riquadri o finestre successivi creati per questa sessione di tmux erediteranno l'UFAM, ma non verranno visualizzati in altre sessioni.

La spiegazione di DJJ mi porta un'altra possibile soluzione alla mente:

Prima tmux/ screenè in esecuzione:

1. Accesso.
2. Inizia un'istanza di ssh-agent.
3. Inizia tmux/ screencon le variabili di ambiente per questo ssh-agent.

Non è stato possibile utilizzare l'inoltro SSH al client ma non è stato richiesto.