SSH не передает переменную среды LANG

888
Scott Colby

Я использую сервер Debian ( uname -vвыход #1 SMP Debian 4.9.65-3+deb9u1 (2017-12-23)). Когда я вхожу в систему с любого из нескольких клиентов (среди прочего, ноутбук MacOS 10.13 с ssh по умолчанию, приложение «Prompt» на iOS) LANG=C, несмотря на вход LANG=en_US.UTF-8с клиента. Вот некоторая соответствующая информация:

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

Итак, sshзаявки на отправку LANG, sshdзаявки на прием LANGи LANGне заданы ни в одном из bashфайлов запуска / завершения работы.

Я знаю, что мог бы «исправить» это с помощью параметра ~/.profileили какого-то такого, но меня больше интересует, почему среда не проходит должным образом.

Редактировать:

Я только что заметил, что LANGимя в MacOS и Debian отличается. Это все еще не работает, однако:

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

Изменить 2:

Оказывается, эта разница в именах не является проблемой Mac-vs-Linux. locale -aсообщает другое имя для локали, чем используется $LANG. Я не удосужился выяснить, почему.

3
Может быть, он перекрывается какой-то обработкой профиля при входе в систему на сервере? Та же проблема здесь между двумя Ubuntus ... LANG кажется забитым, но другие envvars переносятся правильно. xenoid 6 лет назад 1

1 ответ на вопрос

3
Kamil Maciorowski

В моем Kubuntu или Debian есть такой файл /etc/default/locale:

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

Упоминается в разных /etc/pam.d/*файлах. Это фрагмент /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

Теперь из man 5 pam.conf:

Когда приложение предоставления привилегий с поддержкой PAM запускается, оно активирует свое присоединение к PAM-API. Эта активация выполняет ряд задач, наиболее важными из которых являются чтение файла (ов) конфигурации: /etc/pam.conf. В качестве альтернативы это может быть содержимое /etc/pam.d/каталога. Наличие этого каталога приведет к игнорированию Linux-PAM /etc/pam.conf.

Когда пользователь входит в систему через SSH, sshdразветвляется, и в этот момент он /etc/pam.d/sshdвыполняет свою работу. Видите man 8 pam_env, он отвечает за установку / удаление переменных среды. Я не был уверен, будут ли sshdвилы до или после приема переменных от клиента, поэтому я сделал простой тест. Я закомментировал эту единственную строку на моем сервере Debian:

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

и проблема, которую вы указали, была исправлена ​​(проверено LANG=C ssh myserverв моем случае). Я раскомментировал строку, и проблема снова появилась.

Вот откуда в моей системе также появилась переменная. Запуск `dpkg -conconfigure locales` позволил мне установить новое значение по умолчанию. Также интересно - вывод `locale -a`,` en_US.utf8`, не соответствует имени, для которого установлена ​​переменная, `en_US.UTF-8`. Какой странный мир мы создали для себя. Scott Colby 6 лет назад 0

Похожие вопросы