SSH übergibt keine LANG-Umgebungsvariable

939
Scott Colby

Ich betreibe einen Debian-Server ( uname -vAusgabe #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)). Wenn ich mich von einem der Clients (MacOS 10.13 Laptop mit Standard-SSH, der "Prompt" -App unter anderem unter iOS) anmelde LANG=C, obwohl ich vom Client eingegangen bin LANG=en_US.UTF-8. Hier 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_*

So sshbehauptet zu entsenden LANG, sshdbehauptet, die Annahme zu sein LANG, und LANGnicht in einem der eingestellt wird, bashStart / Stop - Dateien.

Ich weiß, ich könnte dies mit einer Einstellung in ~/.profileoder etwas "beheben", aber ich interessiere mich mehr dafür, warum die Umgebung nicht richtig durchlaufen wird.

Bearbeiten:

Ich habe gerade bemerkt, dass der LANGName auf MacOS und Debian anders ist. Das funktioniert aber immer noch 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

Edit 2:

Dieser Namensunterschied ist kein Mac-vs-Linux-Problem. locale -ameldet einen anderen Namen für das Gebietsschema als von $LANG. Ich habe mich nicht darum gekümmert, warum.

3
Möglicherweise wird es durch eine Profilverarbeitung überschrieben, die die Anmeldung auf dem Server durchführt. Das selbe Problem hier zwischen zwei Ubuntus ... LANG scheint unübersichtlich zu sein, aber andere Envvars werden korrekt übertragen. xenoid vor 6 Jahren 1

1 Antwort auf die Frage

3
Kamil Maciorowski

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

Wenn eine PAM-fähige Berechtigungsanwendungsanwendung gestartet wird, aktiviert sie ihre Anbindung an die PAM-API. Diese Aktivierung führt eine Reihe von Aufgaben, die wichtigsten ist das Lesen der Konfigurationsdatei (en): /etc/pam.conf. Alternativ kann dies der Inhalt des /etc/pam.d/Verzeichnisses sein. Das Vorhandensein dieses Verzeichnisses führt dazu, dass Linux-PAM ignoriert wird /etc/pam.conf.

Wenn sich ein Benutzer über SSH anmeldet, sshdverzweigt er sich und dies ist der Moment /etc/pam.d/sshd, in dem er seine Arbeit erledigt. Siehe man 8 pam_env, es ist für das Setzen / Deaktivieren von Umgebungsvariablen verantwortlich. Ich war mir nicht sicher, ob sich sshdGabeln vor oder nach dem Akzeptieren von Variablen von einem Client befanden, 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 Problem, auf das Sie hingewiesen haben, wurde behoben ( LANG=C ssh myserverin meinem Fall getestet ). Ich kommentierte die Zeile und das Problem tauchte wieder auf.

Von hier stammt auch die Einstellung der Variablen auf meinem System. Durch Ausführen von "dpkg-reconfigure locales" konnte ich den neuen Standard festlegen. Interessant ist auch, dass die Ausgabe von `locale -a`,` en_US.utf8`, nicht mit dem Namen übereinstimmt, auf den die Variable `en_US.UTF-8` gesetzt ist. Was für eine fremde Welt haben wir für uns geschaffen. Scott Colby vor 6 Jahren 0

Verwandte Probleme