Conflicting TERM env var with SetEnv feature.

Raphael Medaer rme at escaux.com
Fri Nov 16 03:01:27 AEDT 2018


Hi,

According to D. Miller's commit "add a SetEnv directive to ssh_config
that allows setting" (7082bb58a) we are now able to set remote
environment var from SSH client.

However I have an issue with env var "TERM". Indeed, ssh client is
already sending term through the session. Thus if I specify an other
TERM thourgh SetEnv (for instance "SetEnv TERM=xterm-256" in my SSH
config), this value will be overridden with my local TERM even if I
added TERM in "AcceptEnv" on server side. I guess because the session
is initialized a little bit later..

Here is some log..
```
$ cat <sshd log>
(...)
sshd[35546]: debug2: Setting env 0: LANG=en_US.UTF-8
sshd[35546]: debug3: receive packet: type 98
sshd[35546]: debug1: server_input_channel_req: channel 0 request env reply 0
sshd[35546]: debug1: session_by_channel: session 0 channel 0
sshd[35546]: debug1: session_input_channel_req: session 0 req env
sshd[35546]: debug2: Setting env 1: TERM=xterm-256color
sshd[35546]: debug3: receive packet: type 98
sshd[35546]: debug1: server_input_channel_req: channel 0 request shell reply 1
sshd[35546]: debug1: session_by_channel: session 0 channel 0
sshd[35546]: debug1: session_input_channel_req: session 0 req shell
sshd[35546]: Starting session: shell on pts/1 for remote-user from
127.0.0.1 port 56081 id 0
(...)

$ echo $TERM
rxvt-unicode-256color

$ cat /etc/ssh/sshd_config
(...)
# Allow client to pass locale environment variables
AcceptEnv LANG LC_* TERM
(...)
```

Don't know if I'm right but I would suggest one of the following fixes:

  1. Fix in sshd (server side): I guess we can consider TERM env var
as de facto allowed var for sshd. Then in session we can skip setting
term from "session parameters" and use variable from SetEnv
  2. Fix in ssh (client side - probably easier): If the TERM is set in
SetEnv, replace session term. => Not any change needed in server side.

I would enjoy to propose a patch if you agree ... with preference for (2) !

R. Medaer


More information about the openssh-unix-dev mailing list