Почему я должен повторно устанавливать env vars в tmux при повторном подключении?

В основном я работаю над подключением mac и ssh / tmux к машине Linux, чтобы выполнить свою работу. У меня есть ssh-agent, запущенный на машине Linux. у меня есть

set -g update-environment "SSH_AUTH_SOCK SSH_ASKPASS WINDOWID SSH_CONNECTION XAUTHORITY"

в моем .tmux.conf . Тем не менее, всякий раз, когда я снова присоединяюсь к этой сессии, я должен запускать

 tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK 

для того, чтобы новые окна tmux правильно установили $SSH_AUTH_SOCK . Я бы предпочел не делать этого. Есть идеи?

Обновить

Думаю, я не объясняю это хорошо. Вот моя функция оболочки, чтобы открыть оболочку на удаленной машине:

 sshh () { tmux -u neww -n ${host} "ssh -Xt ${host} $*" } 

Когда tmux запускает эту команду ssh, $SSH_AUTH_SOCK не установлен, даже если он установлен в моей локальной среде. Если я поместил это в среду tmux с помощью команды setenv выше, все будет хорошо. Мой вопрос: зачем мне вообще запускать команду setenv?

Обновление 2

Больше информации:

Когда я присоединяюсь к существующему сеансу, $SSH_AUTH_SOCK не устанавливается в среде tmux (или глобальной среде).

 % tmux showenv | grep -i auth_sock -SSH_AUTH_SOCK 

Если я установил его вручную, все будет работать:

 % tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK 

Если я отсоединяюсь и снова подключаюсь, $SSH_AUTH_SOCK возвращается к не установленному.

4 Solutions collect form web for “Почему я должен повторно устанавливать env vars в tmux при повторном подключении?”

Поскольку я получил Bounty, я полностью отдаю свой ключ-комментарий ради полноты – и чтобы не задавать посетителям ту же проблему на неправильном пути:

Tmux удалит переменные среды

На странице руководства Tmux говорится, что среда обновления удалит переменные, которые не существуют в исходной среде […], как если бы команда -r была присвоена команде set-environment ».

По-видимому, это вызвало проблему. См. Ответ Криса ниже . Тем не менее, я до сих пор не могу представить, как переменная может отсутствовать в «исходной среде» и все же будет действительна во вновь создаваемом окне tmux …


Предыдущий ответ:

Как работает пересылка SSH

На удаленной машине взгляните на среду вашей оболочки после установления соединения 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 

Важным здесь является SSH_AUTH_SOCK, который в настоящее время установлен на некоторый файл в / tmp. Если вы изучите этот файл, вы увидите, что это сокет домена Unix, и он связан с конкретным экземпляром ssh, с которым вы подключались. Важно отметить, что это изменяется при каждом подключении.

Как только вы выйдете из системы, этот файл сокета исчез. Теперь, если вы перейдете и снова подключите сеанс tmux, вы увидите проблему. У этого есть среда, с которой первоначально был запущен tmux – который мог быть неделими назад. Этот конкретный разъем уже давно мертв.

Решение

Поскольку мы знаем, что проблема связана с пониманием того, где находится текущий сеанс аутентификации SSH, давайте просто поместим ее в предсказуемое место!

В файле .bashrc или .zshrc на удаленном компьютере добавьте следующее:

 # 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 

Я не думаю, что вам даже нужно добавить команду update-environment в ваш tmux.conf. Согласно странице man , SSH_AUTH_SOCK уже покрывается по умолчанию.

кредит

Мой ответ – отрывок из этого сообщения в блоге от Mark 'xb95' Smith, который объясняет ту же проблему для экрана .

Я понял это. Короткий ответ, мне нужно было удалить SSH_AUTH_SOCK из update-environment . Поскольку это было в этом списке, значение сдувалось каждый раз, когда я снова подключался. Спасибо @djf за подсказку. Скринирующий бит с страницы руководства tmux (1) в разделе update-enviroment :

Любые переменные, которые не существуют в исходной среде, должны быть удалены из среды сеанса (как если бы команда -t была задана команде set-environment).

Вместо использования tmux для обработки моего ssh-agent у меня есть bash с его помощью:

 ### 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 ### }}} 

У меня это в моем ~ / bashrc , и он отлично работает.

Объяснение djf дает другое возможное решение:

Перед запуском tmux / screen :

  1. Авторизоваться.
  2. Запустите экземпляр ssh-agent .
  3. Запустите tmux / screen с переменной среды для этого ssh-agent .

Это не могло использовать SSH-переадресацию для клиента, но об этом не просили.

  • Tmux - Получить количество панелей в текущем окне в переменной bash?
  • Различные конфигурации tmux для разных сеансов?
  • Невозможно использовать F1, F2, F3, F4 в качестве префиксного ключа
  • Перемещение панели tmux в окно
  • Отрегулируйте толщину границы в tmux
  • Как остановить tmux, фиксируя последовательности клавиш?
  • переназначение Caps Lock на клавишу Ctrl в tmux
  • Как разделить окно tmux на третьи?
  • tmux - Catch 22 с «неизвестным ключом: WheelUpPane» для osx и Ubuntu
  • apt-get версия tmux устарела
  • Цвет печатается справа при написании собственного скрипта в byobu
  • Linux и Unix - лучшая ОС в мире.