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...
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
