>> Actually if you use "-o" it's also overridden. Looking at
sshd
>> logging, it seems that the env var is overridden because of session
>> mechanism (aka "not ordering of parameter source").
>> Thus is it a non-issue due to priority of configuration source ? Does
>> it mean that the priority is "env var" > "cmd line
arguments" >
>> "configuration directive" ?
>
> Tl;dr: you are right, and TERM is special.
>
> Reading the source, I see that TERM is treated specially.? This is
> explicit in ssh_config(5), which says, "Note that the TERM environment
> variable is always sent whenever a pseudo-terminal is requested as it
> is required by the protocol."
>
> Whether or not the configuration should be able to force a different
> TERM than the environment is a matter for debate. TERM is used far and
> wide, and needs to be consistent with the actual terminal hardware, so
> forcing its value in ssh's configuration file seems wrong.
>
> Note, also, /etc/ssh/ssh_config is not *the* ssh configuration, merely
> the default.? Any user can replace it with a file of their own
> choosing.
Yes.
But even ~/.ssh/config is not enough to override $TERM;
and 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?
Forcing the local commands to run with the minimum compatible terminal
emulation is bad; needing an alias or so to fix that isn't right either;
and having to change ~/.profile (or .bashrc etc.) on _all_ remote
machines doesn't sound like a nice solution, too.
For me, the sweet spot would be a "Match" block in ~/.ssh/config with
a
"SetEnv" directive in it - but exactly that isn't possible right
now...