☰

SSH no pasa la variable de entorno LANG

tag-icon • tag-icon bash ssh debian environment-variables sshd
SSH no pasa la variable de entorno LANG

Estoy ejecutando un servidor Debian ( uname -vsalida #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)). Cuando inicio sesión desde cualquiera de varios clientes (computadora portátil macOS 10.13 con ssh predeterminado, la aplicación "Prompt" en iOS, entre otros), LANG=Ca pesar de pasar LANG=en_US.UTF-8desde el cliente. Aquí hay alguna información relevante:

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_*

Por lo tanto, sshafirma estar enviando LANG, sshdafirma estar aceptando LANGy LANGno está configurado en ninguno de los basharchivos de inicio/apagado.

Sé que podría "arreglar" esto con una configuración ~/.profileo algo así, pero estoy más interesado en saber por qué el entorno no se transmite correctamente.

Editar:

Me acabo de dar cuenta de que el LANGnombre es diferente en macOS y Debian. Sin embargo, esto todavía no 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

Edición 2:

Resulta que esta diferencia de nombres no es un problema entre Mac y Linux. locale -ainforma un nombre diferente para la configuración regional que el utilizado por $LANG. No me he molestado en investigar por qué.

Respuesta1

En mi Kubuntu o Debian hay un archivo /etc/default/localecomo:

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

Se menciona en varios /etc/pam.d/*archivos. Este es un 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

ahora desdeman 5 pam.conf:

Cuando se inicia una aplicación de concesión de privilegios compatible con PAM, activa su conexión a PAM-API. Esta activación realiza una serie de tareas, siendo la más importante la lectura del archivo(s) de configuración: /etc/pam.conf. Alternativamente, este puede ser el contenido del /etc/pam.d/directorio. La presencia de este directorio hará que Linux-PAM lo ignore /etc/pam.conf.

Cuando un usuario inicia sesión vía SSH, sshdse bifurca y es el momento en que /etc/pam.d/sshdhace su trabajo. Verman 8 pam_env, es responsable de configurar/desconfigurar las variables de entorno. No estaba seguro de si sshdse bifurcaba antes o después de aceptar variables de un cliente, así que hice una prueba simple. Comenté esta única línea en mi servidor Debian:

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

y el problema que usted señaló se solucionó (probado LANG=C ssh myserveren mi caso). Descomenté la línea y el problema volvió a aparecer.

información relacionada