Comment 44 for bug 920749

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 :)