☰

SSH übergibt die Umgebungsvariable LANG nicht

tag-icon • tag-icon bash ssh debian environment-variables sshd
SSH übergibt die Umgebungsvariable LANG nicht

Ich verwende einen Debian-Server ( uname -vAusgabe #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)). Wenn ich mich von einem der verschiedenen Clients aus anmelde (macOS 10.13-Laptop mit Standard-SSH, die „Prompt“-App auf iOS usw.), wird LANG=Ctrotz der Eingabe LANG=en_US.UTF-8vom Client eine Verbindung hergestellt. Hier sind einige relevante Informationen:

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

Gibt also vor, sshzu senden LANG, sshdgibt vor, zu akzeptieren LANGund wird in keiner der Start-/Herunterfahrdateien LANGfestgelegt .bash

Ich weiß, dass ich das mit einer Einstellung ~/.profileoder so etwas „beheben“ könnte, aber mich interessiert mehr, warum die Umgebung nicht richtig übergeben wird.

Bearbeiten:

Mir ist gerade aufgefallen, dass der LANGName unter macOS und Debian unterschiedlich ist. Das funktioniert jedoch trotzdem nicht:

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

Bearbeitung 2:

Wie sich herausstellt, handelt es sich bei diesem Namensunterschied nicht um ein Mac-Linux-Problem. locale -ameldet einen anderen Namen für das Gebietsschema als den von verwendeten $LANG. Ich habe mich nicht darum gekümmert, den Grund dafür zu ermitteln.

Antwort1

In meinem Kubuntu oder Debian gibt es eine Datei /etc/default/localewie:

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

Es wird in verschiedenen /etc/pam.d/*Dateien erwähnt. Dies ist ein Fragment von /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

Jetzt abman 5 pam.conf:

Wenn eine PAM-fähige Anwendung zur Erteilung von Berechtigungen gestartet wird, aktiviert sie ihre Verbindung zur PAM-API. Diese Aktivierung führt eine Reihe von Aufgaben aus, von denen die wichtigste das Lesen der Konfigurationsdatei(en) ist: /etc/pam.conf. Alternativ kann dies der Inhalt des /etc/pam.d/Verzeichnisses sein. Die Anwesenheit dieses Verzeichnisses führt dazu, dass Linux-PAM ignoriert /etc/pam.conf.

Wenn sich ein Benutzer über SSH anmeldet, sshdforkt sich selbst und dies ist der Moment, in dem /etc/pam.d/sshdseine Arbeit erledigt wird. Sieheman 8 pam_env, es ist für das Setzen/Aufheben von Umgebungsvariablen zuständig. Ich war mir nicht sicher, ob sshdForks vor oder nach dem Akzeptieren von Variablen von einem Client erfolgen, also habe ich einen einfachen Test gemacht. Ich habe diese einzelne Zeile auf meinem Debian-Server auskommentiert:

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

und das von Ihnen angesprochene Problem wurde behoben ( LANG=C ssh myserverin meinem Fall getestet). Ich habe die Zeile auskommentiert und das Problem trat erneut auf.

verwandte Informationen