Je travaille principalement sur un mac et ssh/tmux attaché à une machine Linux pour faire mon travail. J'ai ssh-agent en cours d'exécution sur la machine Linux. j'ai
set -g update-environment "SSH_AUTH_SOCK SSH_ASKPASS WINDOWID SSH_CONNECTION XAUTHORITY"
dans mon .tmux.conf . Pourtant, chaque fois que je me rattache à cette session, je dois courir
tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK
pour que les nouvelles fenêtres tmux aient $SSH_AUTH_SOCK régler correctement. Je préférerais ne pas avoir à le faire. Des idées ?
Mettre à jour
Je pense que je n'explique pas bien cela. Voici ma fonction shell pour ouvrir un shell sur une machine distante :
sshh () {
tmux -u neww -n ${host} "ssh -Xt ${host} $*"
}
Lorsque tmux exécute cette commande ssh, $SSH_AUTH_SOCK n'est pas défini, même s'il est installé dans mon environnement local. Si je mets cela dans l'environnement de tmux avec le setenv commande ci-dessus, tout fonctionne bien. Ma question est la suivante :pourquoi dois-je exécuter la commande setenv ?
Mise à jour 2
Plus d'informations :
Lorsque je m'attache à une session existante, $SSH_AUTH_SOCK n'est pas défini dans l'environnement tmux (ou environnement global).
% tmux showenv | grep -i auth_sock
-SSH_AUTH_SOCK
Si je le configure manuellement, les choses fonctionnent :
% tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK
Si je détache et rattache, $SSH_AUTH_SOCK redevient non défini.
Réponse acceptée :
Depuis que j'ai reçu le Bounty, je republierai mon commentaire clé par souci d'exhaustivité - et pour éviter de mettre les visiteurs ayant le même problème sur la mauvaise voie :
Tmux supprimera les variables d'environnement
La page de manuel de Tmux indique que update-environment supprimera les variables "qui n'existent pas dans l'environnement source […] comme si -r était donné à la commande set-environment".
Apparemment, c'est ce qui a causé le problème. Voir la réponse de Chris ci-dessous. Cependant, je n'arrive toujours pas à imaginer comment la variable pourrait être absente dans "l'environnement source" et pourtant être valide dans la fenêtre tmux nouvellement créée...
Réponse précédente :
Fonctionnement du transfert SSH
Sur la machine distante, jetez un œil à l'environnement de votre shell après avoir établi la connexion 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
L'important ici est SSH_AUTH_SOCK qui est actuellement défini sur un fichier dans /tmp. Si vous examinez ce fichier, vous verrez qu'il s'agit d'un socket de domaine Unix - et qu'il est connecté à l'instance particulière de ssh sur laquelle vous vous êtes connecté. Surtout, cela change à chaque fois que vous vous connectez.
Dès que vous vous déconnectez, ce fichier de socket particulier a disparu. Maintenant, si vous allez et rattachez votre session tmux, vous verrez le problème. Il a l'environnement du lancement initial de tmux - ce qui aurait pu être il y a des semaines. Cette prise particulière est morte depuis longtemps.
Connexe:shell teste si la chaîne de plusieurs lignes contient le motif spécifié dans la dernière ligne?Solution
Puisque nous savons que le problème est de savoir où se trouve le socket d'authentification SSH actuellement actif, plaçons-le simplement dans un endroit prévisible !
Dans votre fichier .bashrc ou .zshrc sur la machine distante, ajoutez ce qui suit :
# 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
Je ne pense même pas que vous deviez mettre une "commande update-environment" dans votre tmux.conf. Selon la page de manuel, SSH_AUTH_SOCK est déjà couvert par défaut.
Crédit
Ma réponse est un extrait de cet article de blog de Mark "xb95" Smith qui explique le même problème pour l'écran.