Behaviour of $SSH_CLIENT and $SSH_TTY variables after suspending/detaching tmux session over ssh

[rstor]

I am learning to use tmux and encountered the following behaviour which I am unsure is normal:

1) I remote into my FreeBSD system over ssh, start a tmux session, then suspend it, and end the ssh session.

2) Locally on my FreeBSD machine if I start a new tmux session and inspect the $SSH_CLIENT and $SSH_TTY variables they still contain the IP/info of the remote machine.

The same behaviour occurs if I detach from the tmux session in step 1 (instead of suspending)

Why is this? Since this is a new tmux session on my local machine shouldn't these variables be null? (If on the local machine I enter into the suspended/detached session, and exit it, then re-enter tmux then both variables are null as I would expect them to be)

 

[SirDice]

Variables aren't changed in a running shell session. So within tmux you start the shell, it has certain variables it inherits (including the SSH_CLIENT, etc). When you disconnect tmux that shell is still running with the variables set the way they are. When you reconnect via ssh and pick up tmux again that shell was still running and would have the same variables as when it first started.

When you create a new window within tmux it would start a new shell, which would inherit the variables from your current shell environment.

 

[zirias@]

When you create a new window within tmux it would start a new shell, which would inherit the variables from your current shell environment.

Are you sure about this? Would actually surprise me.

When a new tmux session is started, a daemon process is launched, which will be the parent for all shells started within tmux (and, trivially, processes inherit their environment from their parent).

So, certainly possible it works the way you describe, but that would require tmux to explicitly implement a behavior of updating the daemon's environment from an newly connected client. I don't think it would be very intuitive after all, what should be done on multiple connected clients, last one wins?

 

[SirDice]

When a new tmux session is started, a daemon process is launched, which will be the parent for all shells started within tmux (and, trivially, processes inherit their environment from their parent).

I think it's the tmux attach that passes the current variables to the running process. But I might be wrong on that. It certainly doesn't change the variables on already running shells within that tmux session.

 

[zirias@]

I think it's the tmux attach that passes the current variables to the running process. But I might be wrong on that.

Just saying that would be possible, but it would surprise me because IMHO it's kind of counter-intuitive if the last client to attach "wins" about the environment but maybe I should just test it to know for sure

It certainly doesn't change the variables on already running shells within that tmux session.

That however would be technically impossible anyways, at least AFAIK you can't just change the environment of another process, not even as the parent....

 

[rstor]

Variables aren't changed in a running shell session. So within tmux you start the shell, it has certain variables it inherits (including the SSH_CLIENT, etc). When you disconnect tmux that shell is still running with the variables set the way they are. When you reconnect via ssh and pick up tmux again that shell was still running and would have the same variables as when it first started.

When you create a new window within tmux it would start a new shell, which would inherit the variables from your current shell environment.

When the tmux session is detached during the SSH session and then on the local machine, when I start a new tmux session (by just issuing 'tmux') shouldn't these variables be null for the new local tmux session (as I would think it would be a new shell for a new session)?

I tried creating a new window and the same behavior exists: When the tmux session is detached during the SSH session on the local machine I attached back to this session, created a new window, and the variables still contain the values for the previously detached SSH session. Also if on the local machine I create a new session, and then a new window, the variables still contain the values for the previously detached SSH session.

zirias@: So, certainly possible it works the way you describe, but that would require tmux to explicitly implement a behavior of updating the daemon's environment from an newly connected client. I don't think it would be very intuitive after all, what should be done on multiple connected clients, last one wins?

I found that whoever initially starts the tmux session (and then detaches), it will set these two variables for that machine. So if I first start tmux on my local machine and detach the session, then SSH to my machine and start a new tmux session, the two variables would reflect the values for my local machine (null).

 

[rstor]

I was looking at the following link:
https://www.babushk.in/posts/renew-environment-tmux.html

After creating a .tmux.conf file and adding:
set-option -g update-environment "SSH_CLIENT SSH_TTY"

The variables now remain independent when a new session is created. Which is what I was expecting to be the case by default.

Also after adding the above line to my .tmux.conf file:
When re-attaching to an existing session it appears to remember the original sessions variables of the system that first initiated the session. However now if I create a new window (as SirDice was mentioning) for the existing session, the new window appears to inherit the properties of the current environment.

 

[Eric A. Borisch]

Check out the ENVIRONMENT section of tmux(1). Excerpted here:

ENVIRONMENT
When the server is started, tmux copies the environment into the global
environment; in addition, each session has a session environment. When a
window is created, the session and global environments are merged. If a
variable exists in both, the value from the session environment is used.
The result is the initial environment passed to the new process.

So long as you have a tmux session running (detached or not), the tmux server persists. (Running tmux list -s will show you the running sessions or tell you if there is no server running, for example.)

If the first tmux session is launched under SSH, and the server spawned at that time is still alive (the number of running -- not necessarily attached -- sessions has never dropped to 0), a new session (perhaps from a console, not over SSH) will inherit any values that aren't updated by its own launching environment from the server. This is true when launching a new shell under tmux, as you're still re-using the running tmux server. This is why your $SSH_* variables are persisting.

 

[SirDice]

Tried to verify this on a blank machine, only tmux is installed.

dice@fbsd-test:~ % echo $SSH_CLIENT
192.168.10.60 63969 22

Then started tmux,

dice@fbsd-test:~ % echo $SSH_CLIENT
192.168.10.60 63969 22

So far so good and the expected result. I then disconnect the tmux(1) session with CTRL-A, D. Leaving that shell inside the tmux session running. And logoff on that machine. Then a new connection shows me:

dice@fbsd-test:~ % echo $SSH_CLIENT
192.168.10.60 64051 22

Shows a different source port for the connection, which would be correct, as it's random for every connection.

Attaching the existing session:

% tmux at
dice@fbsd-test:~ % echo $SSH_CLIENT
192.168.10.60 63969 22

This show the 'old' SSH_CLIENT from the previous connection. Which makes sense as those environment variables aren't retroactively set in existing shells.

You're right zirias@, a new window doesn't get the 'new' values of the shell.

dice@fbsd-test:~ % echo $SSH_CLIENT
192.168.10.60 63969 22

Again, the 'old' SSH_CLIENT info. Now detaching the session and creating a new tmux(1) session also shows the 'old' values.

dice@fbsd-test:~ % echo $SSH_CLIENT
192.168.10.60 63969 22

The 'new' tmux(1) session appears to connect to the already existing tmux(1) and spawns shells inheriting the environment variables from the original tmux(1) session. Removing all existing tmux sessions, then creating a new one, does correctly inherit the new SSH_CLIENT environment variable.

Eric A. Borisch beat me to it. It has to do with new sessions (or windows) inheriting the environment variables that are already set in the first tmux session.

set-option -g update-environment "SSH_CLIENT SSH_TTY"

Yes, that seems to be the solution:

     update-environment[] variable
             Set list of environment variables to be copied into the session
             environment when a new session is created or an existing session
             is attached.  Any variables that do not exist in the source
             environment are set to be removed from the session environment
             (as if -r was given to the set-environment command).

 

[cracauer@]

Right, this is the crux. Unlike screen tmux has a "central" server managing the sessions and messing with variables for all of them. Big difference.

I only start completely new sessions with new sockets to suppress any variable sharing. My sessions are completely independent, like screen sessions.