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

Question

Estou executando um servidor Debian ( uname -v output #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23) ). Quando faço login de qualquer um dos vários clientes (laptop macOS 10.13 com ssh padrão, o aplicativo "Prompt" no iOS, entre outros), LANG=C , apesar de passar em LANG=en_US.UTF-8 do 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, ssh alega estar enviando LANG , sshd alega estar aceitando LANG e LANG não está sendo definido em nenhum dos arquivos bash de inicialização / desligamento.

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

Editar:

Acabei de notar que o nome LANG é 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 -a informa um nome diferente para o código de idioma do que é usado por $LANG . Eu não me preocupei em investigar o porquê.

    

Answer 1

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

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

É mencionado em vários arquivos /etc/pam.d/* . 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, em man 5 pam.conf :

When a PAM aware privilege granting application is started, it activates its attachment to the PAM-API. This activation performs a number of tasks, the most important being the reading of the configuration file(s): /etc/pam.conf. Alternatively, this may be the contents of the /etc/pam.d/ directory. The presence of this directory will cause Linux-PAM to ignore /etc/pam.conf.

Quando um usuário efetua login via SSH, sshd se bifurca e é nesse momento que /etc/pam.d/sshd faz seu trabalho. Consulte man 8 pam_env , ele é responsável por definir / desativar variáveis de ambiente. Eu não tinha certeza se sshd forks 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 com LANG=C ssh myserver no meu caso). Eu descomentei a linha e a questão reapareceu.