A little gotcha with SSH connection sharing

June 26, 2012

I've written before about SSH connection sharing (and how I use it), but I should mention that there is one little obscure gotcha with it. The one gotcha is that all sessions inherit at least one thing from the initial session, instead of setting it up from scratch.

Specifically, X forwarding is only set from the initial session. All ssh sessions over the shared connection channel will use the X forwarding set up for the initial session and thus talk to whatever X display it was connected to, regardless of what their own $DISPLAY is set to (and even if it's not set to anything). If the initial session had no X forwarding (perhaps because it was started outside of X), then no subsequent session will have it.

This is not the case for port forwarding, where a subsequent session can set up a new port forwarding. It's also not the case for the various environment variables that SSH normally propagates to the server; you can have different settings for things like $TERM or $LANG in different sessions over the same shared connection.

(I don't know what happens with ssh agent forwarding; I don't have a test environment because I don't use a ssh agent or agent forwarding myself.)

Now, I will admit that this is an obscure gotcha; most people will never run into it because they won't be using the client machine with different $DISPLAY settings at the same time. I'm peculiar this way because I sometimes wind up logged on to my office workstation from home at the same time as my regular office environment is running (complete with its ssh connection sharing).

Sidebar: workarounds and solutions

The real solution is that the ssh ControlPath setting should have a substitution for the local $DISPLAY value; you could then make and find control sockets that were specific to the $DISPLAY (or lack thereof) that the initial master session supported.

My original hack solution was to use an uncommon variant of the hostname of the target servers in the script where I was setting up and using shared connections. Then when I ssh'd to the host by hand I'd naturally use the common hostname and thus not find the shared connection. This had the drawback that I'm not using the shared connection if I ssh to the host by hand from inside my regular office environment, even though I could and it would be more efficient.

My current solution is a cover script for ssh that checks to see if $DISPLAY is set and if it isn't, forces 'ControlPath none' to effectively turn off shared connections. This is not completely ideal or correct, but solves all of the immediate problems.

(In retrospect, a better but more complex solution would be to use a cover script to set ControlPath to something where I manually included the value of $DISPLAY.)


Comments on this page:

From 68.195.91.180 at 2012-06-26 10:39:36:

can you provide an example? not getting it from your description.

By cks at 2012-06-26 12:08:15:

Suppose, not hypothetically, that I start up my usual environment on my office workstation. This establishes a shared ssh connection to apps0, one of our login servers; because it's running inside my usual environment it forwards X to my display. Later I go home, log in to my office workstation from my home machine and run 'ssh apps0' to once again log in to the login server. Because this is using the shared ssh connection that was initially established as part of my environment, my new login on apps0 has a $DISPLAY set that points to the forwarded X connection. Now I run emacs on the login server, where emacs sees that $DISPLAY is set and opens up an X window. But this window does not appear on my home machine; it appears on my work machine, because that's where the forwarded X connection goes. Oops.

(In fact I do not forward X from my home machine because it runs too slowly, so what I really wanted is for emacs to run in plain terminal mode and my new 'ssh apps0' session should not have a $DISPLAY at all.)

Written on 26 June 2012.
« Why sophisticated line editing is not in the kernel
One root of my problem with GNU Emacs »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Tue Jun 26 00:32:38 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.