Passing the terminal version to the server side is useful for programs
that depend on some terminal features (for instance, to make sure that
some query escape sequence will receive an answer).

In the case of xterm, it is provided by XTERM_VERSION, which should be
added to the SendEnv line in /etc/ssh/ssh_config and to the AcceptEnv
line in /etc/ssh/sshd_config.

Alternatively, standardize something like that for all terminals.

We've had the same discussion last time when it was about LC_*.

It's generally a bad idea to change the secure default of not
forwarding/accepting anything.

Due to past errors, we're already in the unfortunate situation that
this is done for an arbitrary number of vars, and regrettably the
maintainer refused to clean that up.

But we shouldn't increase the list even more, just because some think
that a certain variable may be useful to pass on.
Otherwise we just see more and more people who have their special
wishes and sooner or later we end up with "*".

Especially for terminals and shells there are special env vars galore
(e.g. VTE, BASH, etc. pp.)



It's configurable, so why can't you just set it on those systems where
you need it?


Best wishes,
Chris.

I completely disagree that passing XTERM_VERSION is not secure
(this RFE is about this particular variable, and not anything else).

FYI, this may be useful for Emacs in order to avoid silent file
corruption.

This is a silly argument. No-one has ever asked for "*".

The remote shell is not necessarily the same, so that there is
no reason to pass shell-related variables by default. Perhaps
VTE_VERSION could be useful, but this isn't even clear.

For ssh_config, I agree that this isn't really necessary, since the
user can have its own .ssh/config settings. But conversely, this has
no effect on the security.

But for sshd_config, it requires a change from the administrator
of the machine, and many administrators will not try to change the
defaults.

Alternatively this could be controlled by a debconf option, with two
choices:

1. One that doesn't accept any environment variable (possibly, not
   even $TERM).

2. One that accepts locale and terminal related variables, which is a
   good compromise for machines that support both shell accounts and
   specific commands.

I completely agree that one shouldn't pass too much. For instance,
GREP_OPTIONS could be very harmful for specific commands since it
modifies the standard behavior of GNU grep.

Hey

Am 29. Juni 2015 14:25:15 MESZ, schrieb Vincent Lefevre <
vincent@vinc17.net>:

To be honest, I think it's at best naive to assume, that one can
predict whether or not the passing of any such env may be secure or not
- at worst it's ignorant.

No one can know how a variable may be used on a certain system.
While you may assume for your systems, that the xterm variables are
only used by that and only on a save manner, another user may interpret
them completely different.
And only very few variable names have a really standardised (i.e. not
just by convention but rather by POSIX or similar) meaning, and this
are the only one for which one can assume how they're used.

Well if emacs does file corruption unless some variable is present,
than you should probably file a bug there...

I said "sooner or later"... and you already saw below that there are
many further variables for which people may wish to have them
automatically exchanged.
And VTE is just one of many terminal emulators.

Sending XTERM_VERSION would be surely not enough, one would at least
need TERM as well, I'd guess.

This is a wrong claim that you cannot make, except perhaps in your very
own limited usage scenario.
Actually, I'm quite sure that I've already gave you some good examples
in our last discussion about env vars and SSH.

Vars like LC_*, VTE*, TERM, etc. may affect how programs (on the server
side) produce their output.
That alone may already be a security breach, depending on how systems
are used (consider e.g. that only certain programs are allowed to run).
When the output of such programs is then further parsed by other
programs (e.g. run on the server) which decide security critical
things, one could possibly break that parsing by setting up
locales/terminfo/etc. such way, that it cannot be parsed any longer.
Or maybe, they simply don't it intentionally.

If you want to open up things on your personal systems respectively the
systems you use, you should rather go into discussions with the
respective administrators, and not try to get the same done by
introducing it as default settings in Debian.
configurable via Debconf... why not.
But the default should rather go to even remove LC_* and at least not
adding any further vars - it has a reason why upstream has chosen the
default as it is.

The problem with your debconf proposal are:
- who decides which vars are in the list for the weaker setting
- could we accidentally mangle up configs
- shouldn't this whole thing be something that the admin/user needs to
intentionally configure, rather than having some auto-magic-out-of-the
-box™?
Than you should also see why all other options, including
XTERM_VERSION, LC_*, LANG, etc. are too much - in some or the other
way, they all alter the behaviour/output of some programs, behaviour
which may however be expected/required/security critical.



Best wishes,
Chris.

Which is by far not the only use case of ssh.
Actually there are many major use cases where no pty is involved at all
(and where ssh serves just as a crypto transport layer), but where
these variables may still have an effect.

One may of course consider programs that interpret such variables when
no pty is connected buggy,... but I guess that's simply the world as it
is.

I guess there are a countless scripts, which e.g. use the presence of
such variables (and/or their content) to decide whether to add terminal
escape sequences (again, may be considered buggy, but that's as it is).
But if there is actually no terminal, then these sequences may break
further parsing and change expected (and possibly security relevant)
behaviour on the server side.
I guess this would improve things a tiny bit, but I still think we'd
unnecessarily tickle the dragon's tail by doing so.

And what seems to be rather like a strategy to cope with difficult
sysadmins, is IMHO not enough justification to implement this change
for which no-one can safely say whether or not it has any problematic
impact in certain environments.
Well, it was myself who brought up another bug not so lang ago, where I
tried to have Debian's ssh restrict the list to at least the well
defined LC-vars and not LC_* (which of course doesn't solve the problem
you mention here).

What was actually a little change (as every even non-decent sysadmin
can revert it within seconds) provoked an outcry by some people as if
this would cause the world's end. Colin didn't resist the pressure and
in the end I've been quite heavily criticised.

So I guess you can imagine what would happen if you demand to go to the
safe default of not sending/accepting anything.
As I've said,... I don't think we can really forecast whether or not
some script uses any of these variables in a way that may be used for
attacks or simply break things.

I don't say that I know a program where this is possible, but I think
no one could really blame a script hacker if he uses those variables
(as they're nowhere reserved).
For XTERM_* it may seem obvious that these would "belong" to XTerm.
But then imagine what comes next, as I've said VTE.
There may be people who never heard about "VTE" and use the acronym for
something completely different.
Sure... very much more dangerous...

And even if one would assume, that it may be highly unlikely that
SSHENV_* vars are already used somehow... what would we really get by
that?
Either programs would then need to understand e.g. SSHENV_TZ... rather
unlikely that this happens on a broad base.
Or the vars would need to be reassigned to their canonical name within
the session, and this makes the whole thing useless again (or may
simply not work due to permissions).
The ForceCommand option wouldn't be enough... there are other ways in
SSH to restrict the executed commands.

I see where you're heading towards:
You're idea is basically to restrict the accepted env vars whenever the
user couldn't set them just manually after login... right?


Sounds like a nice idea, but doesn't work in practise:
Nothing prevents the remote server's admin to run special shells where
env var setting isn't possible.
He could even forbid execution of any foreign programs (using selinux
and the like),... so no real way for the client to circumvent this.

So in the end we cannot generally predict whether the user could have
set env vars anyway or not.



Long story short, a change like what's been requested in this bug may
seem subtle, and not being very security relevant.
But that's a big misapprehension.


Further, I think we should try not to deviate[0] from upstream
behaviour even more as we already do (and the existing cases are
already questionable enough from a security PoV).

If at all, such requests should perhaps first discussed upstream, but I
guess their point is clear in that case.



Cheers,
Chris

[0] With the exception of cases where we'd just harden things more, e.g
by disabling unsafe algos per default and that like.
Such changes cause at worst immediate breakage (which would be
immediately noticed),... but no possibly hidden issues.

On the other hand, having the wrong charmap on the other side is a
security issue, because remote utilities could send characters that
they think to be printable, but are actually control characters /
escape sequences due to the wrong charmap interpretation.

I wish SSH could pass the charmap, so that the LC_* hack would no longer
be useful.

A SSH user should read the SSH documentation. If SSHENV_* is
documented by SSH, then I don't see any problem with that.
If you complain about SSHENV_*, why not complaining about
the existing SSH_ORIGINAL_COMMAND too?

But...

This would be better.

Well, also with command="command" in the authorized_keys file.
This would cover most needs.

IMHO, an admin who takes the time to set up such special shells
and so on, could also take some very little time to change the
sshd Debian defaults.

Well but there one knows / must assume at least that this can happen:
When one remotely accesses a system and processes output from there, it
must be assumed that there are different locales/etc. and appropriate
means taken.
But programs on remote side shouldn't need to assume that they're
invoked remotely.

But practically,... are there any issues? Most systems likely either
use C or UTF-8, and I'd be tempted to say it's a their problem if they
use some obscure charmap.
Wouldn't that basically end up in the same concerns?
If one doesn't have a globally standardised list of "reserved" env
vars, then IMHO the duty is to be set on the responsible side.

By that I mean, a program that runs on the remote side, shouldn't have
the duty to take into account that it may be executed from via another
host.
It hast the "right" to assume it's usual environment.

The duty should be on the side who is doing the remote call (i.e. the
client) respectively the sysadmin/user who maintains SSH on the remote
side.


"SSH user" as you write above is however the developer of the remotely
running program,... as you assume he'd be a SSH user and should
therefore read the docs.

I know this sounds all quite philosophical,... but where would that
end?
Can the developer of some application (and the sysadmins) really be
expected to:
a) take into account that some application may run from remote with a
potentially even maliciously changed environment?
b) if we start making exceptions of variables beyond e.g. POSIX,...like
XTERM_* or VTE*, can we expect developers and admins to keep up with
that (possibly growing) list? That they adapt scripts/programs which
may be ages old and/or unmaintained, so that they don't collide with
such variables?
Theoretically it's the same problem.
In practise it works, however, for those reason:

1) hopefully not one accidentally uses these names for other purposes,
completely unrelated to SSH.

2) Those special vars are at least consistent across all OpenSSH, i.e.
it's not a Debian speciality that SSH_ORIGINAL_COMMAND is set, while it
would be for e.g. XTERM_VERSION

3) And the main differences with the SSH_* vars is: sshd sets their
value, it's not really env var passing as in the sense of
XTERM_VERSION, where an arbitrary value can be set.
problem of difficult sysadmin from systems which oneself doesn't
control,... I'd rather says the responsibility lays at the other side.

Further, this isn't such an completely obscure scenario: A special
shell could be something like gitolite.
It's invoked via ssh, it writes files to the disks, these files are
perhaps somehow parsed later for authz questions and so on.
The default behaviour of ssh is to not accept env vars. And the default
behaviour of most programs/servers, I'd know, is to assume "if the
envvar is there, then it'save". That's why e.g. apache's suexec deletes
everything except a few ones which are known to be safely set.

So again, I don't think it's the responsibility of all these people to
secure themselves against a possibly growing list of var names which
may or may not affect their programs.


You should further take into account, that if we make an exception now,
further desires may sooner or later grow.
Why not forwarding things like HTTP_PROXY* (which may include some
password) ... if the user uses e.g. Tor locally, he may want to have
the same done out-of-the box remotely.
Or why not forwarding stuff like XDG_* or GTK_*? If the user runs GUI
applications remotely any maybe have his homedir mounted there, it
could "help" to provide a more homogeneous "experience" (e.g. same GTK
theme).
*shrugs*

This examples may sound exaggerated, but I think it demonstrates quite
well how problematic these things may be; btw. not only in terms of
security but also data privacy (e.g. do I really want, that arbitrary
remote sides get to know which local I run, without my explicit
consent? e.g. whether I'm French, German or Chinese?).

In the end, it should be clear to everyone that by default, SSH is a
clear cut between a local and a remote system.
Anything the integrates the sides more closely, like the env var
passing may do, or like SSH agent forwarding, should be possible - but
not done by default.


Best wishes,
Chris.

This is not possible. Or this would mean that the remote programs
can only output US-ASCII (which is compatible with everything).

Yes, I had issues in the past.

Well, ISO-8859-1 is not an obscure charmap and still exists in Debian.
Moreover I fear that with a C terminal, some UTF-8 sequences sent by
the remote side may be interpreted a escape sequences (if some bytes
are in the 0x80-0x9f range).

In what way?

Anyway, the upstream recommendation is to use AcceptEnv, which is
precisely what Debian is doing.

The goal is to have SSHENV_* as being reserved.

I don't see why. Why would some program accidentally use SSHENV_FOO
but could not accidentally use SSH_ORIGINAL_COMMAND?

Well, IMHO, SSHENV_* (or similar) should become official upstream...
unless upstream thinks that this is not necessary and the current
AcceptEnv is fine.

According to sshd(8), "The command originally supplied by the client
is available in the SSH_ORIGINAL_COMMAND environment variable."

Since it is supplied by the *client*, it can be quite arbitrary.

Similarly, the special shell could delete most of the environment when
starting.

BTW, a ssh server can have several users, with different needs:
some will need some environment variable passing, others won't
need that and can always clean up the environment before doing
anything else (say, start with "env -i" or do something similar).
shouldn't use SendEnv in his config file!

Note: I'm not sure whether the /etc/ssh/ssh_config SendEnv settings
can be overridden. If this is not possible, then the SendEnv directive
should be removed from this file. This is not a problem for the user,
who can add SendEnv directives in his .ssh/config file if he wishes
to pass environment variables.

I don't understand what you mean.
My point was, applications/systems use different locales. Nothing will
change that.
Thus when you process output from a remote application on the local
system, you must assume that this is happening or assure that the
expected locale is going to be set remotely as well.
But the later doesn't mean that it should be done automagically and
generally per default.

Is there a strong reason to use it instead of UTF-8? (of course this
alone doesn't fix your problem :) ).
See... the same, just looked at from the other side, is the reason why
we shouldn't try to make these things automagically working.

Plus there is no real guarantee that by accepting something like TERM,
LC_*, etc. at the server side even guarantees that the client get's
what it likes.

For TERM this is most obvious: The terminfo files on the remote side
may have a different version as locally, so even when one transmits it
per default it still make be wrong in the end.
And I wouldn't bet that this will be better for version string
variables like XTERM_VERSION.
Vars like this tend to be used improperly by 3rd party apps, making
them sooner or later immutable or wrongly set.
Again take TERM... many other terminal emulators != xterm (or is it
just GNOME? ;) ) still set it to "xterm", thereby breaking the whole
idea of TERM.
There's no guarantee that this doesn't also happen for more clearly
versions vars.
In fact, I know some ugly hacked scripts that set things like
BASH_VERSION unconditionally for obscure reasons - whether bash is used
or not.

All these things count to the many reasons why env vars are quite often
considered problematic from a security PoV and towards my point of not
automatically accepting/sending them.

Doesn't it also potentially affect the output/behaviour of programs?
upstream doesn't set a default and is strongly against having a default
that would send/accept variables.
They even point to the security concerns in the manpage.

AFAIU, they have the same policy that I try to defend here:
It's important to have Send/AcceptEnv so that people can (hopefully
knowing what they're doing) send/accept envvars.
But not per default.

I still don't understand how this would help you, as you'd still need
to feed that vars back into their real names for things to work
automatically.

So it seems a bit as if you just look for some (per default) white
listed tunnel, where I'd rather say it seems like a hacky solution for
the real problems of "difficult" sysadmins.

Some days ago, a package like "thefuck" or so was added to the NEW
queue, along with a discussion about whether that name is acceptable
for Debian.
This in turn reminded me about the "Lumia" which is former Nokia's
smartphone but also (IIRC) a Spanish slang word for "prostitute" or
something like that.

In other words, what may seem obvious (i.e. that an env var of a
certain name "belongs" to a certain sytem) to you and me, may be not to
someone else.

I still have concerns about this and would think it's rather not so
good from the security POV (but of course better than directly
sending/accepting e.g. LC_*)

But in any case, *if* such "tunnel" namespace would be send/accepted
per default, than this should be discussed/decided at upstream.
oops,... for SSH_ORIGINAL_COMMAND you're of course right, sorry,.. I
had my minds circling around SSH_CLIENT, SSH_CONNECTION and that like.

Well as I've said before, I also don't like SSH_* very much (which
doesn't mean I'd have a better solution ;-) ).
But SSH_ORIGINAL_COMMAND is at least not generally set, but rather only
when command="command" and I think ForceCommand are used, which both
again, isn't the case per default.

This would be a bad design paradigm.


- It's error prone: an arbitrary number of applications would need to
be adapted, and all future applications would need to take the same
steps for protecting themselves.

That's just the reason why we e.g. don't do that env var sanitisation
in each and every cgi script, but why apache has suexec which blocks
everything for all of them.


- Protecting themselves against something caused by a system which they
may not even have direct business with.
In other words, it pushes away responsibilities from those causing the
change (i.e. the remote connection system - SSH) to those haven't
caused it.


- If such paradigm would be followed,... i.e. allow all changes and let
the others do the work to protect themselves against it, it would be
basically impossible for applications to keep up with that.

See above, the "This would be a bad design paradigm." part.
- environment="NAME=value" in authorized_keys
- PermitUserEnvironment in sshd_config
  (notice again, that the default to this directive is of course "no"
  for security reasons - just as with Send/AcceptEnv)
- Match/Host blocks that select config directive based on the User/Host
in ssh[d]_config

But the same applies here, we shouldn't add further variables that are
set/send/accepted per default and we should ideally remove those which
alrady are.

I think in the end, but sides must be protected, server and client.
This is why I make not difference between sending/accepting env vars.

In ssh usually (there are some strange special cases where this
behaviour is a little bit altered) the first occurrence of a directive
defines the value with later ones being ignored.
So it can be overwritten.


Best wishes,
Chris.

You should learn how terminals work. When using a terminal, the remote
charmap MUST be the same as the local one (or be a subset), otherwise
the terminal cannot interpret the byte sequences correctly.

So, if there is no way to tell the remote side what the local charmap
is, then the only possibility is that the remote side uses a charmap
compatible with every other charmap, i.e. US-ASCII.

If there is no reason to use ISO-8859-1, then why hasn't it been
removed from Debian (and other OS)? This would make things much
simpler (software testing, etc.).

FYI, again, TERM transmission is part of SSH, and this is AFAIK not
configurable: it is transmitted to the other side.

That's true, and that's why the user needs to fix things by rc files
on the other side. And that's why some non-standard env variable is
needed to transmit the charmap (I use LC_CHARMAP), because the standard
LC_* variables do not (always) contain this information. Still, the
only way to get such information is to transmit it to the remote side,
and SSH developers decided that SendEnv/AcceptEnv was the way to do
(except for TERM, which is always transmitted when a pty is requested,
i.e. when it makes sense).
user can always change the default. When I get an account on a machine,
one of the first things I do is to install terminfo files in my home
directory, so then I always have the same ones on all machines.

Such terminal emulators are broken, and I don't use them, unless the
user can choose the value of TERM (remember that the user can also
install terminfo files is his home directory).

FYI, this is precisely because of this brokenness that Emacs uses a
timeout for its terminal queries (when TERM is xterm*), so that it
cannot be blocked when the real terminal does not recognize the usual
xterm queries. This timeout leads to corrupt files when the network
has important latency (which happens from time to time), because
the answer to the query (which looks like characters entered by the
user) is written to the file; and a way to avoid the timeout without
the risk of blocking Emacs would be to be able to get more information
via the environment, e.g. XTERM_VERSION.

Note that there is no such brokenness against VTE, so that VTE_*
variables would not be needed.

It allows to get the same output as characters. For instance, if
the charmap is passed correctly, "env LANG=fr_FR cp" will always
output something like:

cp: opérande de fichier manquant
Saisissez « cp --help » pour plus d'informations.

Otherwise one can get garbage in the terminal.

I don't care what upstream does. With Debian, the default is not
to have restricted user environments: when SSH is installed, any
local end user can log in via SSH. So, it makes sense to have a
default AcceptEnv following this.

In any case, if you think that there is any risk with SSHENV_FOO,
then there is also a risk for SSH_ORIGINAL_COMMAND.

Anyway, if some program wants to use SSHENV_FOO or SSH_ORIGINAL_COMMAND
for its own use, it should unset it first. This is good programming
practice.

But if one doesn't use them, then the user can run any command by
default, and in particular, change the environment and do much more
things.

Wrong.

???

But SendEnv is an exception:

  Multiple environment variables may be separated by whitespace or
  spread across multiple SendEnv directives.
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^

i.e. it seems that a SendEnv directive is not overwritten.

However I could check that the SendEnv line in /etc/ssh/ssh_config
only applies to Host *, not to specific host in the user's .ssh/config
file.

2015-06-30 13:30:50 +0200, Vincent Lefevre:
[...]
[...]

Or use luit  that has been designed for that:

From a UTF-8 terminal:

luit -encoding 'ISO 8859-1' ssh host-known-to-use-latin1

Or:

ssh -t host luit

(assuming luit is installed on host).

(unfortunately it doesn't seem to support the /new/ Western
Europe charset iso8859-15).

2015-06-30 15:04:17 +0100, Stephane Chazelas:
[...]
[...]

Sorry, it does support it, but it seems it fails to detect it
properly from the locale:

$ LC_ALL=fr_FR.iso885915@euro luit locale currency_symbol
Warning: couldn't find charset data for locale fr_FR.iso885915@euro; using ISO 8859-1.
¤

$ LC_ALL=fr_FR.iso885915@euro luit -encoding 'ISO 8859-15' locale currency_symbol
€

Sure... I haven't said that I wouldn't know, have I? o.O
Seems to work for me quite well in practise and I connect to hundreds
of different nodes here at the supercomputing centre, with different
distros and versions thereof.
Probably because most of these systems are simply set up to use either
UTF8 or something compatible.

But the potential issue I've described is still in place.
If the remote side would accept things like charmap/locale
automatically it may change it's behaviour/output (e.g. the sequences
may be redirected to a file and not go to your terminal).
That could possibly break things.

Yes, and what I've told you here was, that even though this is
transmitted, you have no guarantee that things really work,... as TERM
may be wrongly set (e.g. as GNOME does) or the terminfo files may be
newer/older at the remote side, and so on.
Which is a nice solution, but I fail to see how any of this justifies
that we send/accept even more env vars that may cause troubles.

What keeps you from also just setting your LC_*, XTERM_* and so on in
your remote user's .profile/.bashrc/etc. *if* your sysadmins are so
uncooperative not to add them to the accept list?
Hehe,... I had similar arguments when I reported this upstream (IIRC at
the Debian level my bug report was simply ignored)... but they brought
up some obsucre reasons why VTE/Gnome Terminal is amongst the few
emulators where it's simply necessary that they fake xterm.

Perhaps you can try to convince them to behave nicely :)
a) on terminals
b) when these have the correct charmap set.

If for some reasons the output goes into a file, which can happen, then
the binary representation would be different, wouldn't it?
Well I can't help you if you simply ignore intentional and good
choices.
Then you could again argue to that we simply Accept/Send *, including
e.g. LD_LIBRARY_PATH.
May be of no harm for your use cases, cause when you can log in anyway
you can also set it manually.

But then again, you'd simply ignore the needs of all those users of
SSH, that use it differently from your personal use cases.

As indicated before, I don't think it would be appropriate to change a
safe default to something that helps you with your sysadmins or charmap
problems, or that may help e.g. myself with my special setups,... which
may however cause issues to anyone else, especially not if those issues
are possibly security relevant and if they wouldnd't be immediately
visible.
So since one cannot know in advance which names may ever be used by
some other application, one would basically need to unset everything
(except those names for which one knows that one definitely uses them
securely, regardless of their content), right?

Then we're basically back to having this job done safely by e.g. ssh
(which it does per default).

And as I've said before,... expecting that every program can/would do
such proper cleanup is simply naive - which is again just the reason
why we don't place this responsibility not into e.g. each and every CGI
script but into Apache.

Of course.
But it's not acceptable that we silently put responsibility on the
other people and possibly cause them troubles just because you, me or
anyone else thinks that his use case of SSH would be the major use case
and that all others would need to adapt to it.

You said that some users would need env var passing some not.
Again you wish for the default to be to transmit more (or everything)
and want to put the burden/responsibility of cleaning things up on the
others.
Transmitting "more" would be helpful for your use cases,... so have it
done and, and let everyone else adapt,... ranging from possibly years
old code which no one really knows anymore.

As I've said, that would bad behaviour/paradigm.

Instead I showed you some ways where you could selectively configure
the send/accepted environment based on the authenticating user, the
user logged in to, and so on... by which one wouldn't need to possibly
disturb everyone else.
Hmm I guess that behaviour simply assumes that one cleverly sets up
ssh[d]_config and not sets these directives on a too global scope...
which again fits the default in OpenSSH to not Send/AcceptEnv.


Cheers,
Chris.

However it doesn't work from non-UTF-8 terminals.

This is not very good, because the default encoding on the remote
machine may change without notice.

Any solution without writing "luit" explicitly?

2015-06-30 16:45:59 +0200, Vincent Lefevre:

Yes, though if you don't use a UTF-8 terminal you won't be able
to see arbitrary characters from those remote machines.

That's also potentially affected by the remote user's
.cshrc/.bashrc/.zshenv...

Other solutions can be GNU screen which can translate encodings
on the fly.

In any case, if you can't guarantee that the remote host will
have a locale with the same charset as used by your terminal,
you'll have to have something do some translation (and best is
to use a UTF-8 terminal emulator). Or fall-back to ASCII.

Sending TERM is absolutely necessary because different terminals
behave in different ways.

Because their values depend on the client side.

I doubt I can. I had similar problems with the iTerm developer, who
didn't want to have its own TERM value. The TERM value was configurable,
but with very few possible choices, and I had to use xterm-color, with
a modified terminfo specifically for iTerm.

For (b), this is exactly the reason why I need to transmit the charmap.

The solution is to set the locales in the script (or in some shell
rc file). That way, it will still work even if the admin chooses to
change the default locales.

It makes no sense to send/accept LD_LIBRARY_PATH because the paths
are typically different on the remote system. So, it will more
likely break things than solve things... possibly even before the
user can correct the value.

No. An application should not use a prefix that is already used,
in particular from well-known tools such as SSH. So, using a SSH
prefix is definitely a wrong idea.

Following your thoughts, what if you have two different applications
using the same environment variable for different purpose? This could
also yield privacy/security problems.

Every sensitive program should do so because of possible clashes
between them.

In a similar way, the shell (or command) started by sshd could do
that. Then this shell or special command would execute the real
program.

Yes, and the only solution I see, and the one recommended by upstream,
is to use SendEnv/AcceptEnv. The other users can easily clean up the
environment with "env -i". But really, this wouldn't even be needed
with SSHENV_* variables, and in practical cases, applications can
just ignore the additional variables (FYI, though transmitted, the
standard LC_* variables are reset by PAM before the user can see the
transmitted values).

You didn't show anything.

Actually more by a change by the admin.

GNU screen doesn't allow one to use the alternate screen, and there
would be the same problem: how to use GNU screen without writing it
explicitly?

For instance:

  ssh host my_command

where my_command is automatically run under GNU screen.

With charmap transmission, everything is transparent.

And that's why SSH sends it... others are not important, thus, they
don't sent by default.

But then you contol both, client and server side.
Just manually set it to the same, and bon.

Yeah,.. the whole situation in that field is quite unfortunate... :(

Well but this is simply not how things are generally handled.
The locale is set system wide and/or by the users. Some DEs (perhaps
GNOME? ;-) ) perhaps override that with their own settings but that
would already be bad as it breaks long standing behaviour.

If you go remotely than apps running there should at first run with the
remote settings (i.e. locale/etc.) and if this is not desired as in
your case it should be your manual duty to adapt/change the settings...
and not the duty of everyone else to adapt to your wishes.
This is absolutely not necessarily the case.... you could simply have
the same distribution or whole software bundles that reside in /opt
/afs or wherever, the later is for example typical here in the LHC
Comuting Grid,... the whole software tree used by the experiments
(including compilers, etc.) is in one standardised tree, identical
amongst all possible distros.

Don't you just get it or are you simply keep ignoring it? There is no
registry or standard who defines what's well known and what's not.

I thought the Lumia example would have quite nicely explained it.

You can just place responsibility on everyone else to know the names
which *you* or *I* think are to be considered well known.

Which is the case.
But of course *only* if such programs somehow inherit their own
environment to other programs (e.g. via execv).... and this is the case
for SSH.

If the invoked program (i.e. programs you run via ssh, like ls, ps and
so on) is not specifically intended as always being invoked from a
potentially hostile environment, than the responsibility to clean the
same up is definitely upon the invoker (in that case, ssh).
Even for programs that could expect a hostile environment (e.g. CGI
scripts) we typically handle the clean up at the invoker level.

That's just how most such systems that I'd know off handle things by
default.

Sure, it could. But the shell is just the shell, and not necessarily a
program designed to be executed from remote,... that's what SSH is
designed for,... and since the potential insecurity comes from the
remote environment it's naturally the responsibility of SSH to clean it
up, not of the shell.

To be hones, this discussion is getting moot... and apparently you're
twisting up words here.
Upstream does explicitly *not* recommend to send/accept any env vars
*by default* which would affect any users, they even warn about it,
which I told you already before.

And in all doing respect, your insistence that all others should clean
up all their stuff because of your personal wishes, seems a bit
arrogant.
As I said before, I still have concerns about this,... but it's
something you should probably discuss upstream.
But as I've said before, I doubt they will auto send/accept all envvars
from the client into their "SSHENV_" counterparts.

And one should probably call it SSH_ENV_ so that it matches the already
used style of OpenSSH's env vars.
If PAM is used (see the UsePAM directive)...

When you invoke ssh like this, it executes the command with <SHELL> -c
"mycommand", where <SHELL> is the shell as set in passwd.

You could simply write a pseduo shell, that if -c is used takes its
argument and invokes these via screen.
Without -c you could simply run the shell itself.