O SSH não está passando pela variável de ambiente LANG


5

Estou executando um servidor Debian ( uname -vsaída #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)). Quando faço login de qualquer um dos vários clientes (macOS 10.13 laptop com ssh padrão, o aplicativo "Prompt" no iOS, entre outros) LANG=C, apesar de ter passado LANG=en_US.UTF-8do cliente. Aqui estão algumas informações relevantes:

client$ env | grep LANG
LANG=en_US.UTF-8
client$ ssh -v server
...
debug1: Sending environment.
debug1: Sending env LANG = en_US.UTF-8
server$ env | grep LANG
LANG=C
server$ grep -in lang /etc/profile ~/.bash_profile ~/.bash_login ~/.profile ~/.bash_logout ~/.bashrc
grep: ~/.bash_profile: No such file or directory
grep: ~/.bash_login: No such file or directory
server$ locale -a
C
C.UTF-8
POSIX
en_US.utf8
server$ sudo sshd -T | grep acceptenv
acceptenv LANG
acceptenv LC_*

Então, sshafirma estar enviando LANG, sshdalega estar aceitando LANGe LANGnão está sendo definido em nenhum dos basharquivos de inicialização / desligamento.

Eu sei que eu poderia "consertar" isso com uma configuração ~/.profileou algo assim, mas estou mais interessado em saber por que o ambiente não está sendo passado corretamente.

Editar:

Acabei de perceber que o LANGnome é diferente no macOS e no Debian. Isso ainda não funciona, no entanto:

client$ LANG=en_US.utf8 ssh -v server
...
debug1: Sending environment.
debug1: Sending env LANG = en_US.utf8
server$ env | grep LANG
LANG=C

Editar 2:

Essa diferença de nomes não é um problema Mac-vs-Linux. locale -areporta um nome diferente para o locale que é usado por $LANG. Eu não me preocupei em investigar o porquê.


1
Talvez ele seja substituído por algum processamento de perfil no logon no servidor? O mesmo problema aqui entre dois Ubuntus ... LANG parece derrotado, mas outros envios são transportados corretamente.
xenoid

Respostas:


5

No meu Kubuntu ou Debian existe um arquivo /etc/default/localecomo:

#  File generated by update-locale
LANG="pl_PL.UTF-8"

É mencionado em vários /etc/pam.d/*arquivos. Este é um fragmento de /etc/pam.d/sshd:

# Read environment variables from /etc/environment and
# /etc/security/pam_env.conf.
session    required     pam_env.so # [1]
# In Debian 4.0 (etch), locale-related environment variables were moved to
# /etc/default/locale, so read that as well.
session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale

Agora de man 5 pam.conf:

Quando um aplicativo de concessão de privilégio que reconhece o PAM é iniciado, ele ativa seu anexo para a API do PAM. Esta ativação executa uma série de tarefas, sendo o mais importante a leitura do arquivo (s) de configuração: /etc/pam.conf. Como alternativa, isso pode ser o conteúdo do /etc/pam.d/diretório. A presença deste diretório fará com que o Linux-PAM ignore /etc/pam.conf.

Quando um usuário efetua login via SSH, sshdele se bifurca e esse é o momento do /etc/pam.d/sshdseu trabalho. Veja man 8 pam_env, ele é responsável por definir / desconfigurar variáveis ​​de ambiente. Eu não tinha certeza se sshdgarfo antes ou depois de aceitar variáveis ​​de um cliente, então fiz um teste simples. Eu comentei esta única linha no meu servidor Debian:

session    required     pam_env.so user_readenv=1 envfile=/etc/default/locale

e o problema que você apontou foi corrigido (testado LANG=C ssh myserverno meu caso). Eu descomentei a linha e a questão reapareceu.


Este é o lugar onde a configuração variável veio no meu sistema também. Corrida dpkg-reconfigure localesme permitiu definir o novo padrão. Também interessante - a saída de locale -a, en_US.utf8não corresponde ao nome para o qual a variável está definida en_US.UTF-8. Que mundo estranho criamos para nós mesmos.
Scott Colby 2/18 de
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.