Comment 4 for bug 920749

A sysadmin, in a non-English speaking country, should set default values (especially for locale related environment values). The natural way to set these is through PAM (works across many shells). I also implemented a no-clobber pam environment setting, but it will not work for ssh AcceptEnv/SendEnv because (IIRC) the environment passed to pam for initialisation is empty - it does not contain pre-set variables with the ssh AcceptEnv/SendEnv variables set. This solution implies to change 2 major components of a Unix system (openssh + PAM) instead of only one (openssh). I also do not see how being conservative (putting AcceptEnv on low priority) is helpful, especially in the case of locales; if I remotely log into a japanese system, I want to be able to type in French and read messages in French). The locales system degrades correctly if the locale does not exist on the target system; the user does not degrade correctly if the remote language is not understood.

In short, I would like some kind of way to have remotely sent variables override any defaults set by PAM. Maybe not all variables, but imagine that for some users, having some incorrect LANG is the same as having the wrong TERM variable (and TERM is dealt with specially in openssh).
Please consider that LC_CTYPE/LANG is as important as TERM as soon as you are not in a pure ASCII language.

Of course, your position is somehow sensible if those were random variable names. But the names for the locale-setting vars are fixed, must be able to get defaults from pam, and must be overriden by the user.

There is always the possibility of local hacks (AcceptEnv/SendEnv on SSH_LANG, use the shell to copy LANG to SSH_LANG if it is not set and from SSH_LANG to LANG if SSH_LANG is set, using the various level of initialisation), but it is really cumbersome.

It is not also obvious why AcceptEnv/SendEnv should not get precedence.
After all, both sysadmins have to agree on which variables are acceptable for import/export in the environment. The default on all computers that I know of is "LANG LC_*". So if ssh cannot export LANG LC_* as soon as there is some default set in PAM (and almost all distributions do that), there is no use of this feature possible by default. Of course, you are free to think that there should be no default set by PAM, but think that in a non-English speaking environment, something has to be done to put a default language (say, French, Japanese or Latvian) for all "normal" users that use the regular login (so that they can read their mails in the correct encoding, almost all programs now read LANG or LC_CTYPE to know which encoding to use).