openssh unix dev - Apr 2022 - AcceptEnv LANG LC_* vs available locales

Hi folks,

forwarding LANG and LC_* variables to the peer seems to be only
reasonable, if the peer supports theses locales. Is there some
workaround for this pitfall? Do you think the server could quietly
ignore unknown locales?

Every helpful hint is highly appreciated

Harri

On 2022/04/25 10:05, Harald Dunkel wrote:
> Hi folks,
> 
> forwarding LANG and LC_* variables to the peer seems to be only
> reasonable, if the peer supports theses locales. Is there some
> workaround for this pitfall? Do you think the server could quietly
> ignore unknown locales?
I think it would be too much magic if the SSH server considered the
contents of these variables. Apart from anything else, it doesn't know
whether particular software that you might be running in SSH might need
some setting that sshd doesn't know about.

If you're using non-default config to pass these variables and have
some places where it's a problem to see an unknown locale, you could
always make your own changes to the variables in .profile on those
systems. (I am guessing that in the majority of these cases the only
actual problem is the noise from Debian's Perl configuration...)

Hi Harald,

Harald Dunkel wrote on Mon, Apr 25, 2022 at 10:05:43AM +0200:
> forwarding LANG and LC_* variables to the peer seems to be only
> reasonable,
Absolutely not, what a terrible idea.

For an introduction to the topic, see

  https://undeadly.org/cgi?action=article&sid=20160308204011

The end of that article specifically discusses ssh(1).
> if the peer supports theses locales. Is there some
> workaround for this pitfall? Do you think the server could quietly
> ignore unknown locales?
Ignore it?  But if it does, then there is nothing it can safely do short
of rejecting the connection.
> Every helpful hint is highly appreciated
As discussed in the above writeup, the only way to make ssh(1)
connections safe it to manually make sure, *before connecting*,
that the same locale is set on both sides - ideally UTF-8.

A special case of that rule is that with OpenBSD *and* the default
OpenBSD xterm(1) configuration on the client side, it is always
safe to connect to other OpenBSD machines, no matter the configuration
on the server.

But even with an OpenBSD client and the default xterm(1) config,
connecting to other operating systems is never safe unless you make
sure you have an ASCII or UTF-8 locale set on the server *before
connecting*.  Forwarding locale variables won't help with that at all.

Yours,
  Ingo