As far as I know, most distributions enable this setting so the client sends its preffered locales to the server. Server explicitly configured with no locales (like it is recommended in the Debian Wiki: http://wiki.debian.org/Locale) end up with no locale (ansi characters only) when SSHed from a Gentoo system. I suggest enabling SendEnv LANG LC_* in /etc/ssh/ssh_config by default. Or maybe someone can tell me why this would be the wrong approach :-P Reproducible: Always Steps to Reproduce: 1. Use a server with no explicit locale configured (Debian default) 2. Connect with ssh from a Gentoo system with unmodified config 3. Try to enter things like üöß etc.
Created attachment 272973 [details] Patch adding the client setting to send locales
should be all set now in the tree; thanks for the report! Commit message: Enable locale env var passing by default http://sources.gentoo.org/net-misc/openssh/openssh-6.0_p1.ebuild?r1=1.1&r2=1.2
"Or maybe someone can tell me why this would be the wrong approach :-P" Of course. See https://bugzilla.mindrot.org/show_bug.cgi?id=1285 ... it is NOT possible to turn this off on per-host basis. In addition to that: svn: warning: cannot set LC_CTYPE locale svn: warning: environment variable LC_CTYPE is cs_CZ svn: warning: please check that your locale name is correct ... server may LACK the locale you are using on local machine.
(In reply to Honza from comment #3) that edge case is uncommon enough i think to not matter. it outweighs the much more common scenario where people want this behavior. if you don't like it, you can easily set the locale vars in your ~/ shell init scripts. or modify your local ssh_config.
(In reply to Honza from comment #3) > "Or maybe someone can tell me why this would be the wrong approach :-P" > > Of course. See https://bugzilla.mindrot.org/show_bug.cgi?id=1285 ... it is > NOT possible to turn this off on per-host basis. In addition to that: > > svn: warning: cannot set LC_CTYPE locale > svn: warning: environment variable LC_CTYPE is cs_CZ > svn: warning: please check that your locale name is correct > > ... server may LACK the locale you are using on local machine. Indeed. I encountered a serious issue where some of the Java applications at my workplace failed to deal with UTF8 correctly after being restarted. Eventually, it transpired that it was only happening in situations where OS X users had signed in prior to issuing the restart command. OS X was allowed to propagate a locale name that is not recognised in Linux, causing it to fall back to the C locale. Also, as klondike pointed out, the decision to accept client specified environment variables has been unhelpful in view of bug 523592. I don't think this was a good call.
It created quite some pain here. My servers have onlye one locale (en_US.utf8), while people connecting to them all have non-english locale on their computer. Had to remove those sshd settings...
(In reply to Thomas Capricelli from comment #6) alternatively, you could fix your server to support the locales your users are interested in ;). there's nothing stopping them from `export LANG=xxx` in their ~/ shell init scripts (which is fairly common).
(In reply to SpanKY from comment #7) I guess this could be argued for long, but in our opinion, a server doesn't need localization. On our computers, we use desktop environments with localization, on servers we use CLI in English. One reason (not even the most important one) being that sysadmin tools are really badly translated.
I got hit by this too. Figuring out what causes the LC_CTYPE and LANG variables to magically change to something else (which in turn causes things like Snapper to outright stop working with a message "Failed to set locale. Fix your system.") was quite annoying. I understand why the patch submitted here makes sense: sending one's locale to the server is a good idea. But why is the *server* also set to accept it by default? Debian servers accept it and that's good, but Gentoo does not build all locales if you follow the handbook (https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Configure_locales), and thus it should also not accept all locales by default. All that would be lost is messages being printed in English until the system admin uncomments the line in sshd_config, and would prevent random system breakage from happening.
(In reply to Dainius Masiliūnas from comment #9) I totally agree with this.
I strongly object to this change having been made in the default sshd_config. Less so, in the case of ssh_config but I still think that it is unjustified. The following comments concern the former ... (In reply to SpanKY from comment #7) > (In reply to Thomas Capricelli from comment #6) > > alternatively, you could fix your server to support the locales your users > are interested in ;). With all due respect, I must call bullshit on this. How exactly do you propose that we "fix" our servers where users are using a platform whose locale names do not accord with those of glibc? Or is the rest of the world supposed to be adhering to a Linux monoculture? In particular, macOS is more popular than Linux for desktop/workstation duties, is markedly popular among developers of various creeds and is immensely popular among tech startups. You, of all people, should know this. Edge case, my foot. > there's nothing stopping them from `export LANG=xxx` > in their ~/ shell init scripts (which is fairly common). Them being everyone other than the OP, I take it? Putting aside the conveniently non-falsifiable notion that this is "fairly common", your sentiments apply in exactly the other direction. There was nothing to stop the OP from configuring his server's locale settings to address this issue, rather than following some dubious interpretation of a suggestion provided by a wiki for another distro, only to drag bugs.gentoo.org when it blows up in his face and he doesn't know how to fix it. Seriously, where does it even suggest that a host should be "explicitly configured with no locales"? Because if that's true, the guys that work on the debian installer didn't get the memo. The reality is that, to end up with everything defaulting to plain C/POSIX, you have to go out of your way to make that happen in a Debian installation. The same goes for Ubuntu and any other derivative that I've tried, as they make use of the same installer and preseed code. For crying out loud, they even have a special C.UTF-8 locale for the generic case. In the course of adhering to some notion of minimalism, he could have at least set LC_CTYPE! If the implications were not understood, why should the rest of us pay a price? Just before writing this comment, I spent one painful hour assisting a user in #gentoo whose issues turned out out to be caused by AcceptEnv. As was the case for me (in comment #5), the root cause of his particular issue was wholly obscure and, even with applicable domain knowledge on my part, it was painful to get to the bottom of. In the interests of keeping this comment somewhat digestible, I'm omitting the exact details of this incident. Suffice to say that it amounts to four people that I have personally encountered as having been affected, and one other who warned of the consequences here. I'll wager that there have been many more that we don't know about. If the narrative was that a setup like Michael's is common-place - and I submit that it is absolutely not - where was the consensus to support it, prior to pushing through a change that diverges from upstream defaults, is accompanied by tangible drawbacks, and has affected other users? SpanKY, I greatly respect your skills and technical acumen, but I think you made a questionable call here, apparently unanimously. Your subsequent comments have the air of being dismissive of the legitimate concerns that have been raised by others, as well as being predicated on a subjective world-view of what constitutes the common case. Of course, I'm in no position to oblige you to listen to anyone, but I would beseech you to consider whether your defense of this policy change was objective, well-considered and truly in the public interest. My feeling is: no, on all three counts. P.S. I work in devops and the users that I support are not interested in messing around with shell init files. They simply have better things to do. And I have better things to do with my heterogeneous environment than add to the ever-increasing pile of gentoo-specific customisations that are enacted by way of configuration management, in order to work around arbitrary downstream decisions that don't honour upstream defaults, just because it accords to a particular maintainer's world view. I would prefer to spend my resources on constructing policy based upon hygienic defaults, not the other way around.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6fdefd62aefe48e72cb5939f38b6421a30e4d5c5 commit 6fdefd62aefe48e72cb5939f38b6421a30e4d5c5 Author: Mike Frysinger <vapier@gentoo.org> AuthorDate: 2018-06-20 21:47:41 +0000 Commit: Mike Frysinger <vapier@gentoo.org> CommitDate: 2018-06-26 08:18:50 +0000 net-misc/openssh: update set of locale vars #367017 Rather than glob all LC_* env vars, hardcode the list based on what POSIX defines and the GNU extensions. In practice, this means we additionally send LANGUAGE, and unregistered or unrelated env vars that happen to start with "LC_" are no longer sent. If someone has a locale related variable that they want to include, they can file a new request for it. We continue to omit POSIX's NLSPATH as that is much more likely to be system specific and have no useful meaning on the remote side. Bug: https://bugs.gentoo.org/367017 ...7_p1-r101.ebuild => openssh-7.7_p1-r102.ebuild} | 18 +- net-misc/openssh/openssh-7.7_p1-r6.ebuild | 451 +++++++++++++++++++++ 2 files changed, 465 insertions(+), 4 deletions(-)
As stated by Honza in 2014, if there is a SendEnv setting in the systemwide ssh_config file, there is no way to override this in the per-user config file. Setting SendEnv is NOT a good default for people that have non-english locales on their machines and ssh to machines that do not support this locale. Gentoo should not have a dubious global default configuration that cannot be overwritten. It is impracticable to assume all remote machines are under the users control and could be configured to support the non-english locale. Therefore I believe this should be reverted. https://bugzilla.mindrot.org/show_bug.cgi?id=1285
Wait, is the only problem that we have set > # Host * > SendEnv LANG LC... instead of > Host * > SendEnv LANG LC... or am I missing something? Because all the other distributions are setting > Host * > SendEnv LANG LC_* (Debian/Ubuntu) or > Host * > # Send locale-related environment variables > SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES > SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT > SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE (RHEL-based)
It should be equivalent. The problem happens because if multiple SendEnv directives are used (global config + user config), their effect accumulates. There is no way to overwrite (remove) the settings from the global SendEnv. I opened a new issue to discuss disabling the SendEnv directive https://bugs.gentoo.org/671928 Based on what Thomas Deutschmann has collected, the same bug report would apply to the other distributions. It seems not sensible to assume that all machines to be accessed via ssh support the same locale as the local machine. Obviously this is not an issue for the majority of people using en_US.UTF-8 on their local machines, but this is an issue for other locales when the remote machine has no support for it. On the other hand, for the majority having en_US.UTF-8, there is anyways no need for SendEnv as the remote likely already defaults to en_US.UTF-8. So in the end it seems the SendEnv default is only to simplify the live of minority users. However, setting the SendEnv directive in the user config specifically for the machines that support the locale, if desired, seems more sensible than forcing to apply SendEnv to all ssh connections, due to resulting breakage if the remote does not support the locale. So actually the current default does not simplify, but causes problems.
vapier brushed off this concern in comment 4, and I happen to agree; it is very unlikely for someone to ssh into another machine that supports locales but doesn't have the necessary locale data installed. There are multiple ways a user can work around this: 1. Edit /etc/ssh/ssh_config locally if root access is possible. 2. Unset the locale variables before calling ssh (env -i ... ssh ...). 3. Reset the variables on the remote site via shell startup scripts.
*** Bug 671928 has been marked as a duplicate of this bug. ***
I am not sure if the situation is that unlikely. In a perfect world, where every remote machine would be well administered and either disable accepting locale env variables or support all possible locales the current approach is great. However, in the real world, many machines running e.g. in the Cloud are based on a default Ubuntu or Debian installation, do not come with locales different than "en_US.UTF-8" and still happily accept the locale variables send by the connecting user. In that case, if the locale is not supported, the remote system will break. Just try executing > LC_CTYPE="zh_CN.UTF-8" python3 -c "print(b'\xce\xb5'.decode('utf-8'))" It will raise an exception if your machine does not provide zh_CN.UTF-8. On the other hand, not sending LC_CTYPE (and like) and defaulting to whatever the remote machine sets as default is sane. It will not result in any breakage. If a user prefers to use the remote system in a different language, but is greated with the result of `LANG=en_US.UTF-8`, it is obvious he must change the language. If a remote system randomly breaks, it is non-obvious what is the reason. Of course there is a way to workaround the current default. But the point is we should use choose sane defaults that also work well in the real world, and not only if all stars align.
I'm wondering, wouldn't it make sense to have the sshd config set to drop locale vars by default, and have locale-gen change the sshd config to accept them if the number of locales generated is high enough? It wouldn't solve all the problems but at least it would be saner in terms of Gentoo-to-Gentoo interactions.
(In reply to Leonard Lausen from comment #18) > I am not sure if the situation is that unlikely. In a perfect world, where > every remote machine would be well administered and either disable accepting > locale env variables or support all possible locales the current approach is > great. A recent case in point: https://github.com/sakaki-/gentoo-on-rpi-64bit/issues/137. This isn't the first such incident I've assisted with since my last comment and I know it won't be the last. Not only was the individual affected tremendously confused by the symptoms, he lacked the domain-specific knowledge to ask the sort of questions that would lead to a rapid diagnosis. But this is only to be expected and the user is certainly not to blame. This incident was, at least, novel to me in so far as it resulted in a misdirected bug report. At any rate, it took a tremendous amount of effort on the part of myself and a few others in the #gentoo channel to perform a root-cause analysis. Not once have I ever seen a Gentoo developer ever be a party to - much less be involved with - such exchanges as and when they occur. Odd, that.
(In reply to Dainius Masiliūnas from comment #19) > I'm wondering, wouldn't it make sense to have the sshd config set to drop > locale vars by default, and have locale-gen change the sshd config to accept > them if the number of locales generated is high enough? It wouldn't solve > all the problems but at least it would be saner in terms of Gentoo-to-Gentoo > interactions. What would be sane is for this change to finally be accepted as the bad decision it was and to be reverted. Not that I am under any illusion of that ever happening. I understand that you mean well but for poorly-implemented, distro-specific utilities to start meddling with sshd_config, based on a vaguely defined heuristic, would be nothing short of preposterous. Save for portage's capability to queue default configs for merging, the distribution should mind its own business and preferably not attempt to impose its rather singular world view in this regard.
The sane default is to disable SendEnv LANG LC_*. It was obvious by then, is obvious with all other distros, and is even more obvious now. This could still be added commented in sshd_config, with a short comment about pro/cons.
Similary, I have been pulling out my hair for a week trying to find out why my emerge @world had several packages failing with the message 'could not set LC_NUMERIC to de_BE.utf8'. I have been searching high and low where de_BE was defined or even mentioned. Until finally I stumbled on this setting. Turns out that I normally connect from a Gentoo PC, and this time from a Mint Linux with a less-than-usual locale setting. I too am in favor of reverting this setting, because if something unexpected happens on the server, the first time one looks is the server. AT THE VERY LEAST, this setting should be explicitly mentioned in the wiki on localisation (with an explanation of why one might desire the setting or not), so that one can consiously decide whether this behaviour is wanted or not.
(In reply to jan vereecke from comment #23) > AT THE VERY LEAST, this setting should be explicitly mentioned in the wiki > on localisation (with an explanation of why one might desire the setting or > not), so that one can consiously decide whether this behaviour is wanted or > not. Anyone with an account can edit the wiki if they so desire.
