Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Updating DISPLAY with ssh and byobu

Tags:

ssh

x11

tmux

byobu

I have the following scenario:

In my work computer (A) I open a byobu (tmux) session.

Inside byobu, I open several terminals. Some of them are local to (A), but in others I ssh to a different computer (B).

I go home, and from my my home computer (C) I ssh to (A), run "byobu" and find all my sessions in (A) or (B).

This works perfectly, except for running X11 applications. I don't leave any X11 application running when I change computers, but just running "xclock" sometimes works and sometimes doesn't ("cannot connect to X server localhost:n.0").

I understand this depends on the DISPLAY variable, and that it would be set up such that X11 would connect to the computer where I ran "byobu" last before creating the session inside byobu, and that could be (A) or (C). My problem is that often I don't know how to fix a session that's not working any more. Sometimes I can just open another session (another tab in byobu) and use the value of $DISPLAY in other sessions, but that only works as long as the new session is open, and not always. In other cases I've been able to detach byobu (F6), re-attach it (run "byobu") and open a new ssh connection to (B), and then that one works, but not the already existing sessions.

I have read some documents like SSH, X11 Forwarding, and Terminal Multiplexers or How to get tmux X display to come back?, but it is unclear to me how they apply (if they do) to my situation. For instance, the .bashrc code of the former, should it be in (A), (B), or (C)?

like image 490
Jellby Avatar asked Mar 24 '17 14:03

Jellby


1 Answers

UPDATE/EDIT I have found the correct way to do this. Simply type this in any of the byobu shells

. byobu-reconnect-sockets

and the DISPLAY environment variable for your new ssh connection, as well as SSH_AUTH_SOCK and several others that may be useful and dependent on the primary login shell (that which you do byobu attach-session -t session_name or for screen backend, byobu -D -R session_name or however you do prefer to do it).

This is all supposed to happen simply by pressing CTRL-F5, but I suspect that like me, your computer is intercepting the CTRL-F5 (for me, I am using iTerm on a Mac) and either doing its own thing with it, or sending the wrong control character sequence so byobu doesn't receive it properly. It's a bit more typing, but sourcing the shell script as indicated above will do the same thing as CTRL-F5 is supposed to do, and will do it for ALL byobu open shells in the session. The rest of my original answer below you can probably now ignore, but I'll leave it there in case it is in someway useful to someone perhaps for some other purpose.

Also, you can edit the byobu-reconnect-sockets script (it is just a shell script) and there are places to add additional environment variables you want updated, so really none of the below is necessary.

(original answer follows)

When you ssh in again and reattach your byobu sessions, it is likely that the ssh forwarded X11 display for your new ssh connection is not the same as the proxy display that initial ssh session created when you launched byobu. Suppose you ssh in for the first time and are going to start a new byobu session with many shells and perhaps many forwarded X11 windows, and this will all work fine, because that first ssh shell sets the DISPLAY environment variable to what it is listening on for X11 connections. This might be something like

[~/]$ printenv DISPLAY localhost:11.0

all shells started by byobu (and tmux or screen on the backend) are going to inherit the setting of all the environment variables that were set when byobu was initially launched, ie, the X11 display that was forwarded for your user for your first ssh connection.

Then you detach your byobu session and go home, and ssh back in. But this time you get a different X11 display, because some other user has localhost:11.0. In your new ssh session that you started at home, the value of DISPLAY might be localhost:14.0 (say). For X11 forwarding through this ssh connection, X11 clients need to connect to the ssh X11 proxy at display localhost:14.0, not localhost:11.0. You will likely not have the authorization keys for localhost:11.0 at that point, someone else will, or worse, if they have disabled X authentication, the X11 windows you are trying to open are going to start showing up on their screen. All you need to do to make it work, is this -

  1. detach byobu
  2. you should now be in the current ssh shell. Do printenv DISPLAY and note the value shown (or copy it)
  3. reattach byobu
  4. In any shell you want to use X11 in, do export DISPLAY=localhost:14.0 (in this example it'd be that value, you'll use whatever value you get for #2 in your case)
  5. X11 will now forward through ssh to your screen as you expect
  6. The catch - you have to do this in every byobu shell that is open separately if you want to use X in that shell. To my knowledge there is no way to set it in all shells except I think there may be a way to run any arbitrary command in all shells at the same time, but I don't know the key sequence to do that off the top of my head.
  7. the annoying - you have to do this every time you detach and disconnect your ssh connection, and then reconnect with ssh and reattach your byobu, as it is likely the DISPLAY environment variable in the ssh shell has changed, but your shells either have what was set for DISPLAY when byobu was initially started, or whatever you have last set it to.
  8. Even if you open new shells in byobu in some later ssh connection, those shells will still inherit the DISPLAY environment variable setting that was set when byobu was first started, all the way back to your first ssh connection. You have to do this with new shells too.

This annoys me constantly and I'd love to take the time to develop some hack of some kind to at least make this less tedious, and best of all would be to have it done along with ctrl-F5, which effectively does exactly all this, but for some other things you often want to reconnect with your new ssh session, especially SSH_AUTH_SOCK for ssh-agent.

like image 198
slowkoni Avatar answered Oct 09 '22 11:10

slowkoni