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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/920749 Title: pam configuration for SSH prevents LANG override To manage notifications about this bug go to: https://bugs.launchpad.net/openssh/+bug/920749/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
