Por que preciso redefinir o env vars no tmux ao reconectar?

31

Eu principalmente trabalho em um mac e ssh / tmux anexar a uma máquina Linux para fazer o meu trabalho. Eu tenho o agente ssh em execução na máquina Linux. Eu tenho

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

no meu .tmux.conf . No entanto, sempre que eu voltar a anexar a esta sessão, eu tenho que executar

tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK

para que as novas janelas tmux tenham $SSH_AUTH_SOCK configurado corretamente. Eu preferiria não ter que fazer isso. Alguma idéia?

Atualizar

Acho que não estou explicando isso bem. Aqui está minha função de shell para abrir um shell em uma máquina remota:

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

Quando o tmux executa este comando ssh, $SSH_AUTH_SOCK é não definido, mesmo que seja definido no meu ambiente local. Se eu colocar isso no ambiente do tmux com o comando setenv acima, tudo funciona bem. Minha pergunta é, por que eu tenho que executar o comando setenv?

Atualização 2

Mais informações:

Quando eu participo de uma sessão existente, $SSH_AUTH_SOCK não está definido no ambiente tmux (ou ambiente global).

% tmux showenv | grep -i auth_sock
-SSH_AUTH_SOCK

Se eu definir manualmente, as coisas funcionam:

% tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK

Se eu desanexar e voltar a anexar, $SSH_AUTH_SOCK voltará a não ser definido.

    
por Chris W. 13.05.2013 / 19:21

5 respostas

12

Eu percebi isso. Resposta curta, precisei remover SSH_AUTH_SOCK de update-environment . Como estava nessa lista, o valor estava sendo perdido toda vez que eu recolocava. Obrigado ao @djf pela pista. O bit saliente da página man do tmux (1) na seção update-environment :

Any variables that do not exist in the source environment are set to be removed from the session environment (as if -r was given to the set-environment command).

    
por 20.05.2013 / 18:16
29

Desde que recebi o Bounty, repostarei meu comentário-chave por completo - e para evitar que os visitantes com o mesmo problema estejam no caminho errado:

O Tmux removerá as variáveis de ambiente

A página man do Tmux informa que update-environment removerá as variáveis "que não existem no ambiente de origem [...] como se -r fosse dado ao comando set-environment".

Aparentemente, o que causou o problema. Veja resposta de Chris abaixo . No entanto, ainda não consigo imaginar como a variável pode estar ausente no "ambiente de origem" e ainda assim ser válida na janela tmux recém-criada ...

Resposta anterior:

Como funciona o encaminhamento de SSH

Na máquina remota, dê uma olhada no ambiente do seu shell depois de estabelecer a conexão 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

O mais importante aqui é o SSH_AUTH_SOCK, que está atualmente configurado para algum arquivo em / tmp. Se você examinar este arquivo, verá que é um soquete do domínio Unix - e está conectado à instância específica do ssh em que você se conectou. Importante, isso muda toda vez que você se conecta.

Assim que você efetua logout, esse arquivo de soquete específico desaparece. Agora, se você for recolocar sua sessão do tmux, verá o problema. Tem o ambiente de quando o tmux foi originalmente lançado - o que poderia ter sido há algumas semanas. Esse socket em particular já está morto há muito tempo.

Solução

Como sabemos que o problema tem a ver com saber onde está o soquete de autenticação SSH atualmente ativo, vamos apenas colocá-lo em um lugar previsível!

No seu arquivo .bashrc ou .zshrc na máquina remota, adicione o seguinte:

# 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

Eu não acho que você tenha que colocar um comando 'update-environment' no seu tmux.conf. De acordo com o man page , SSH_AUTH_SOCK já é coberto por padrão.

Crédito

Minha resposta é um trecho de postagem deste blog por Mark 'xb95' Smith, que explica o mesmo problema para a tela .

    
por 18.05.2013 / 01:58
2

Em vez de usar o tmux para manipular meu ssh-agent, tenho que manipulá-lo com:

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

Eu tenho isso no meu ~ / bashrc , e funciona muito bem.

    
por 13.05.2013 / 19:54
0

A explicação de djf traz outra solução possível para minha mente:

Antes de tmux / screen estar em execução:

  1. Fazer login.
  2. Inicie uma instância de ssh-agent .
  3. Inicie tmux / screen com a (s) variável (s) de ambiente para este ssh-agent .

Isso não pôde usar o encaminhamento de SSH para o cliente, mas isso não foi solicitado.

    
por 18.05.2013 / 02:26
0

Respondi a uma pergunta semelhante no link do StackOverflow. Como essa página apareceu primeiro nas minhas pesquisas do Google, eu quis publicar uma versão resumida aqui.

Para que cada sessão tmux tenha um conjunto de variáveis de ambiente customizadas, você deve adicionar os valores às variáveis de ambiente por sessão do tmux. Veja um exemplo de como fazer isso.

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

A última etapa da exportação explícita do FOO é necessária para que o painel atual capte a variável de ambiente. Quaisquer painéis ou janelas subseqüentes que você criar para esta sessão tmux herdarão o FOO, mas não aparecerão em outras sessões.

    
por 21.03.2018 / 00:41