I feel like this setup violates the principle of least surprise. As a user, sshing into a machine, I have my ssh client configured to SendEnv LC_* and LANG. Awesome. Look, /etc/ssh/sshd_config, the server is even accepting these in its default configuration! Except some setting that I *personally* never would have thought of in pam configuration, completely outside of the control of a mere mortal (read: non-root user) comes in and sets the locale to whatever the person who set up the machine originally configured. And I have no real control over it.
I do recognize the issue raised when there's a difference in client/server locale meanings (my en_US is your en_US.utf8 I think is one someone mentioned), but I feel like that's solveable on the client side by specifying different values to be sent for those variables in their ssh configuration (SetEnv option) Even the ssh_config manpage specifies that... > the Debian openssh-client package sets several options as standard in > /etc/ssh/ssh_config which are not the default in ssh(1): > * SendEnv LANG LC_* So why would it then have a default configuration to stomp all over those environment variables? Am I missing something? I'm not even a non-english user, I was just trying to figure out why emacs when I ssh in shows \u2505 instead of a fancy pipe character, but when I use mosh it works fine, and fell down this rabbit hole :) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/920749 Title: pam configuration for SSH prevents LANG override Status in portable OpenSSH: Confirmed Status in openssh package in Ubuntu: Triaged Status in openssh package in Debian: Confirmed Bug description: The default /etc/pam.d/sshd configuration has: # Read environment variables from /etc/environment and # /etc/security/pam_env.conf. #auth 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. auth required pam_env.so envfile=/etc/default/locale The default SSH client configuration has "Send LC_*" and the default SSH server configuration has "Accept LC_*". The PAM configuration prevents any user-overrides for locale settings. For example, if /etc/default/locale has: LANG=en_US.UTF-8 LC_COLLATE=C Then running "LANG=zh_SG.utf8 LC_COLLATE=en_US.UTF-8 ssh myspecialhost.foo.bar.com" yields: ubuntu@ip-10-12-15-243:~$ locale LANG=en_US.UTF-8 LC_COLLATE=C (output truncated for clarity) While having a blank /etc/default/locale yeilds: ubuntu@ip-10-12-15-243:~$ locale locale: Cannot set LC_ALL to default locale: No such file or directory LANG=zh_SG.utf8 LC_COLLATE=en_US.UTF-8 (output truncated for clarity) I think, although I am not sure, that this is a bug with the default configuration. It means that in order for server to accept multple languages or LC_* bindings, the system locale default would have to be unset. Effectively this is forcing the system default on all users. To manage notifications about this bug go to: https://bugs.launchpad.net/openssh/+bug/920749/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
