como desativar as variáveis ​​SendEnv definidas no ssh_config em ~ / .ssh / config


30

Eu não consegui encontrar isso em lugar nenhum, então estou me perguntando se sou o único atingindo esse problema.

Por padrão, o ssh no Red Hat e no Debian tem pelo menos uma opção ssh_config com a opção SendEnv passando variáveis ​​LC * e LANG na sessão remota. Se alguém não é root para alterar / etc / ssh / ssh_config, como ele pode desativar esse comportamento? A opção SendEnv parece estar se acumulando e não consigo encontrar nenhuma maneira de redefini-la.

E para evitar ser solicitado, eu preciso evitar passar meu código do idioma para testar máquinas para evitar efeitos colaterais em scripts e programas que dependem do código de idioma ser o padrão para a máquina.


Esta não é uma resposta para sua pergunta, mas você pode resolver seu problema invocando os scripts e programas em suas máquinas de teste por meio envou com um script de wrapper?
9758 Scott

2
sim, soluções alternativas são possíveis, mas inconveniente
akostadinov

Respostas:


18

Você não é o único . Conforme documentado, ssh_config(5)você não pode desabilitar SendEnv, porque

Múltiplas variáveis ​​de ambiente podem ser [...] espalhadas por várias diretivas SendEnv.

Se você possui root nas máquinas de teste, pode mudar AcceptEnvpara não aceitar variáveis ​​enviadas pelo cliente.


4
porcaria, vejo apenas -F na linha de comando pode ajudar, mas é muito inconveniente para realmente usar. Veja bugzilla.mindrot.org/show_bug.cgi?id=1285
akostadinov

5

Isso não pode ser feito ~/.ssh/configporque SendEnvnão pode ser substituído.

Usar aliases não funcionará para scripts que chamam ssh.

Uma alternativa é exportar uma função. Por exemplo, em ~/.bashrc:

function ssh() {
    LANG="en_US.UTF-8" \
    LC_ADDRESS="$LANG" \
    LC_IDENTIFICATION="$LANG" \
    LC_MEASUREMENT="$LANG" \
    LC_MONETARY="$LANG" \
    LC_NAME="$LANG" \
    LC_NUMERIC="$LANG" \
    LC_PAPER="$LANG" \
    LC_TELEPHONE="$LANG" \
    LC_TIME="$LANG" \
    LC_ALL="$LANG" \
    /usr/bin/ssh $@
}
export -f ssh

1

Existe uma opção SetEnv, pode-se forçar LANGum valor específico antes de enviá-lo.

Também a página de manual diz que

É possível limpar os nomes de variáveis ​​SendEnv definidos anteriormente, prefixando os padrões com -.

mas não consegui fazer isso funcionar.


Veja bugzilla.mindrot.org/show_bug.cgi?id=1285 , provavelmente isso explicará por que a -abordagem não funcionou. Boa sugestão, porém, para codificar o LANG remoto e outros vars na configuração do ssh. Torna as coisas mais previsíveis. Talvez SetEnvseja uma diretiva mais recente, porque ninguém mais sugeriu isso. SetEnv LANG=en_US.UTF-8
akostadinov

0

Se você estiver usando o bash, poderá configurar um alias ssh = 'LANG = command ssh' para desativar a passagem do LANG para os outros servidores.


0

Você pode usar su - youruserquando estiver logado no ssh. Isso reinicializará o ambiente para o usuário.

Na verdade, você inicializa uma nova sessão com um novo ambiente.


A questão é ter o ambiente saudável automaticamente. E btw su nem sempre é instalado. E você deve digitar sua senha com su. Nao é útil. Existem soluções mais fáceis.
precisa saber é o seguinte

0

De acordo com man ssh:

 -F configfile
         Specifies an alternative per-user configuration file.  If a con-
         figuration file is given on the command line, the system-wide
         configuration file (/etc/ssh/ssh_config) will be ignored.  The
         default for the per-user configuration file is ~/.ssh/config.

Portanto, você pode ssh sem cumprir/etc/ssh/ssh_config especificando explicitamente o arquivo de configuração (padrão) na linha de comando ( ~/.ssh/configé OK que esteja vazio):

$ touch ~/.ssh/config
$ ssh -F ~/.ssh/config your_user@your_host

Você pode criar um alias para isso em ~/.bashrc:

alias ssh="ssh -F ~/.ssh/config"

Reinicie o shell bash, então você pode simplesmente ssh assim:

$ ssh your_user@your_host

Veja meu comentário acima. if one supplies on command line -F, then the system wide config is ignored according to man pagede bugzilla.mindrot.org/show_bug.cgi?id=1285 ; é uma opção, mas não é realmente o recurso desejado.
akostadinov
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.