BWC
Architects
BWC_Architects_Blog_Tilte-Graphic.png

Blog

Goings on at the BWC Architecture Studio

Follow-up to X11-over-SSH post, X11DisplayOffset explained!

OK, so a friend (one of the two people who read this Blog) explained to me more about the whole X11-over-SSH voodoo, and I thought I'd post it here as a follow up. I'm very proud to present that information to the other reader of my Blog, who probably knows it already:
So says my friend SPACEMONKEY:
Hey, I really liked that description of doing the blender  remote stuff (at http://www.becausewecan.org/node/23 ); in the whole 'spirit-of-blogging' thing, I might could shed some light on the X11DisplayOffset thing: Hope you've got some coffee...
In X, you're not limited to having a single remote host fooling around on your desktop (or vice versa). If you wanted to play with two, three, or (even) four other machines, all opening up windows on your laptop, X11 does this by having all those machines open sockets up to the Xserver running on your desktop (which the Xclient finds, typically, by a environment variable called DISPLAY). 'k?
Note this is a different model than, say, telnet or ssh; with those, you connect to the server and the server starts talking to you. With X, you run a program on the server and it connects back (opens up sockets) to your client.
Back in the golden days when no one cared about security (ie, when X11 was developed) that was swell. But, when you introduce ssh, it needs to be able to hijack (tunnel) all the socket data between two machines so it can be encrypted before going over the wire (otherwise it's just a quick packet sniff away from the cover of the NY Times).
Okay, back at the server side, you run a fancy program to look at pictures of puppies. The fancy program tries to open up a window, the local X instance creates a socket (just like normal)... but it can't talk directly to your laptop, as you're running ssh. But, ssh doesn't *know* you're running an X11 program and there's no way for it to (cleanly) know about programs you're running that talk to your laptop, so it can't intercept the socket calls it needs to tunnel the traffic back. And, furthermore, you could ssh into one machine, telnet from that machine to *another* machine, and run a program on that third machine which opens a window back to your laptop (all through the magic of X).
OK, so a friend (one of the two people who read this Blog) explained to me more about the whole X11-over-SSH voodoo, and I thought I'd post it here as a follow up. I'm very proud to present that information to the other reader of my Blog, who probably knows it already:
So says my friend SPACEMONKEY:
Hey, I really liked that description of doing the blender  remote stuff (at http://www.becausewecan.org/node/23 ); in the whole 'spirit-of-blogging' thing, I might could shed some light on the X11DisplayOffset thing: Hope you've got some coffee...
In X, you're not limited to having a single remote host fooling around on your desktop (or vice versa). If you wanted to play with two, three, or (even) four other machines, all opening up windows on your laptop, X11 does this by having all those machines open sockets up to the Xserver running on your desktop (which the Xclient finds, typically, by a environment variable called DISPLAY). 'k?
Note this is a different model than, say, telnet or ssh; with those, you connect to the server and the server starts talking to you. With X, you run a program on the server and it connects back (opens up sockets) to your client.
Back in the golden days when no one cared about security (ie, when X11 was developed) that was swell. But, when you introduce ssh, it needs to be able to hijack (tunnel) all the socket data between two machines so it can be encrypted before going over the wire (otherwise it's just a quick packet sniff away from the cover of the NY Times).
Okay, back at the server side, you run a fancy program to look at pictures of puppies. The fancy program tries to open up a window, the local X instance creates a socket (just like normal)... but it can't talk directly to your laptop, as you're running ssh. But, ssh doesn't *know* you're running an X11 program and there's no way for it to (cleanly) know about programs you're running that talk to your laptop, so it can't intercept the socket calls it needs to tunnel the traffic back. And, furthermore, you could ssh into one machine, telnet from that machine to *another* machine, and run a program on that third machine which opens a window back to your laptop (all through the magic of X).
As a clever hack, what ssh does is open up a range of *potential* sockets on the server machine (when you enable X11Forwarding) and waits for any program to connect any of these sockets, effectively pretending these sockets are the Xserver on your laptop. When some program (presumably the puppy program) connects to these ports, ssh intercepts the X11 data sent (to open windows, draw pictures of puppies, etc) over these fake sockets and tunnels them over an encrypted socket to the ssh on your laptop, and asks the local ssh to open up sockets to your local laptop's Xserver and pass on the commands the server program sent (and you see puppies!)..
The range of sockets the ssh server opens on the remote side starts at... wait for it.... 6000 + X11DisplayOffset.
Now, how is this useful? If you wanted to have *more* than one X11 connection from your laptop to a given server or if there a lot of other people running X clients off your server, you could avoid getting windows destined for your client popping up on other people's machines by setting X11DisplayOffset to a different value. Or, if you were a paranoid type, you could change *your* X11DisplayOffset setting on the server you're using to a different value than the default of '10', which makes it less easy for crackers to get into your machine.
man, I need coffee now...

Jeffrey McGrew