Conflicting TERM env var with SetEnv feature.

[Philipp Marek]

>> if it happens that your local terminal emulation is not available
>> on the remote machine(s), what would be the right place to fix it?
> Is it a trick question? 
No.

Modern "tmux" has a terminal type "tmux" (similar to screen),
but when SSHing into eg. a CentOS7 box this type is not available
- and so ncurses things (like an editor) get severely messed up.

> Isn't the remote machine the only place that
> you can fix ?
No. I offered several different ways to deal with that.


>   Setting TERM on the local machine won't magically make
> a Wyse 60 understand VT220 control codes.
No, but it's the easiest thing to do for mostly-compatible
terminals like screen, xterm, tmux, etc.

> Why not wrap ssh with a shell script to do what you want?
Because that's another point that has to know which machine
I deal with. That means argument parsing compatible to SSH,
perhaps even knowing about SSH host aliases/redirects via
~/.ssh/config, and so on.
Having an SSH "Match" block seems to be the best solution
to me, followed by a check in the remote's .bashrc (which
would have to be duplicated on all affected hosts, and
removed again when an CentOS update allows to use "tmux"
there).

Furthermore, that "SetEnv" in ssh_config works for all but
one environment variable violates the principle of least
surprise, and so I'd consider that a bug in SSH.
Yeah, $TERM is special - but why not let the user override it?