☰

SSH não passando a variável de ambiente LANG

tag-icon • tag-icon bash ssh debian environment-variables sshd
SSH não passando a variável de ambiente LANG

Estou executando um servidor Debian ( uname -vsaída #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)). Quando faço login em qualquer um dos vários clientes (laptop macOS 10.13 com ssh padrão, aplicativo "Prompt" no iOS, entre outros), LANG=Capesar de passar LANG=en_US.UTF-8pelo 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_*

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

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

Editar:

Acabei de notar que o LANGnome é diferente no macOS e no Debian. No entanto, isso ainda não funciona:

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:

Acontece que essa diferença de nomes não é um problema do Mac versus Linux. locale -arelata um nome de localidade diferente daquele usado por $LANG. Não me preocupei em investigar o porquê.

Responder1

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 deman 5 pam.conf:

Quando um aplicativo de concessão de privilégios com reconhecimento de PAM é iniciado, ele ativa seu anexo ao PAM-API. Esta ativação realiza uma série de tarefas, sendo a mais importante a leitura do(s) arquivo(s) de configuração: /etc/pam.conf. Alternativamente, este 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 faz login via SSH, sshdele se bifurca e este é o momento em que /etc/pam.d/sshdfaz seu trabalho. Verman 8 pam_env, ele é responsável por configurar/desativar variáveis ​​de ambiente. Eu não tinha certeza se sshdbifurcava antes ou depois de aceitar variáveis ​​de um cliente, então fiz um teste simples. 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). Descomentei a linha e o problema reapareceu.

informação relacionada