Create an X session over an ssh tunnel
|
| Author | Content |
|---|---|
| Bob_Robertson Mar 01, 2011 1:13 PM EDT |
So lets avoid all the trouble and multiple commands on two machines, and the security bypassing, in the article's first section and just use this: ~$ ssh -Y bob@10.2.3.4 bob$ nethack-x11 and Nethack will run on the remote machine, but display on your local screen. From man ssh: -Y Enables trusted X11 forwarding. Trusted X11 forwardings are not subjected to the X11 SECURITY extension controls. Just saying.... |
| gus3 Mar 01, 2011 1:54 PM EDT |
Or, shorten it to a single statement: ~$ ssh -Y bob@10.2.3.4 "nethack-x11" And when the game exits, so does the "ssh" command. However, the "X session via SSH" is not a real X session; it's merely a forwarded X11 TCP connection, which doesn't require adding the remote client system to the server's xhost list. The window management is still running locally. Read xsm(1) to see what X Session Management is all about. That said, if someone knows how to run all the client programs remotely (including WM or DE), through SSH, and connect to the local server, such a command (or script) would be most welcome! |
| Bob_Robertson Mar 01, 2011 2:34 PM EDT |
Gus, Isn't that "remote log-in" is all about? Oh, right, X still has to run locally, and then connect to the server to say "give me a log-in session please". I've always known about that, and I know that's how the thin-client models work for school-room and other installations, I've even seen the configuration items in one of the X login front ends, but I've never done it. ...and, realizing what you were talking about now, I do NOT remember them being enabled over an ssh tunnel, but I don't see any reason they could not be, if the X login launching script could be changed to launch it like your "nethack-x11" example above. Too bad my server is cooked at the moment, I could try it out. And even make a blog post about it! Woohoo, another topic! |
| gus3 Mar 01, 2011 2:57 PM EDT |
I've tried it so many times, and hit the brick wall each time. I think it'll take a different mind from my own to find it. Just a nit to pick, for safety's sake: The X server always runs locally, on the system you're looking at and typing on. If anything is running remotely, it's X clients. |
| jdixon Mar 01, 2011 3:07 PM EDT |
> That said, if someone knows how to run all the client programs remotely (including WM or DE), through SSH, and connect to the local server, such a command (or script) would be most welcome! I thought I managed to run a startx from an ssh command line using putty and Xming under Windows the last time I tried, but it was so slow I didn't try using it for anything. This would have been two years ago now. I don't remember that I had to set up anything special other than allowing for the -Y option on both ends. This required modifying the sshd server configuration on my Linux end, from memory. |
| cr Mar 01, 2011 3:24 PM EDT |
Once it's back up, you've easily got enough horsepower in that server to run LTSP. I've considered setting that up for corners like the kitchen and the garage, but lacked the time, the network infrastructure (it wants a dedicated switch for the thin clients and a dedicated NIC on the server, treating the server as a bastion host; we're just barely out of the one-flat-10base-segment stage here) and screens. If you're looking at playing around with X sessions, be advised that, at least as of MEPIS 6.5, a MEPIS live-cd has "remote session" as a login-screen option. I was surprised when my younger son's MEPIS box successfully started up an XDM session into KDE1.1 on my RHL6.2 mail-and-text server. Why a live-CD? Because, for testing purposes, it cuts through the issue of opening holes in an existing install's firewall to let the X traffic through (and remembering to close them back up afterwards). Not saying that MEPIS is the only one that does that, just that it's one that I'm sure does. |
| Bob_Robertson Mar 01, 2011 5:45 PM EDT |
I can't remember if it's the GDM or KDM (could be both) login screen that provides an option to open a session from a remote client. In which case any liveCD that didn't automagically put you into a user session has the possibility of doing that if the X client machine (thanks, Gus, I do make that mistake chronically)(or would that be cronically?) is set up to allow such. You guys have given me the topic of my next tech blog post! Thank you! ...ok, not the _next_ post, that will be about putting these two new motherboards into these sad, stumbling cases... My, what two big systems you have! The better to test X my dear! |
| gus3 Mar 01, 2011 6:20 PM EDT |
Both GDM and KDM, although the option might be disabled by default. It might be labeled with "XDMCP" for X Display Manager Control Protocol. However, this is still not through SSH; XDMCP uses UDP for its initial negotiation. (There's also a graphic about the X server and clients at the link.) |
| cr Mar 01, 2011 6:25 PM EDT |
Quoting:...ok, not the _next_ post, that will be about putting these two new motherboards into these sad, stumbling cases... Not until you've tested their power supplies, I hope. Given their history, I really really think you need to look around for a 'scope for that, not just a DVM. @bob: MEPIS is KDE, so likely it's KDM that offers the option if it's the only one. The way Ubuntu tries to hide bootup activity, I still dunno if GDM offers it. @gus: My to-do item about X sessions was to throw together two isolated spare boxes connected by a cat5 crossover cable, drop both firewalls and all restrictions (such as commenting out "DisplayManager.requestPort 0" in /etc/X11/xdm/xdm-config), bang on 'em until either could run an X session hosted by the other, then start putting sensible security back in place until it stopped so I could see what all I was doing wrong in trying to get X running across my network. I got as far as building a crossover cable... There is no such thing as a maskable interrupt when you have kids. |
| Bob_Robertson Mar 01, 2011 7:51 PM EDT |
Cr, I do understand, but I don't OWN a scope, nor does anyone I know in this Cromm-forsaken burg. Gus3, that's a great find. Thanks. The option on the display managers is XDMCP, but I have yet to use it myself so I don't know what the requirements are to configure on the remote machine. It looks like Cr said that it automagically came up from his RedHat 6.1 system. Could be it was turned on by default, RedHat being a "server" kind of install. I'll dig around when I get to writing that article. UDP? I know, in my bones, there is a way to set up a UDP tunnel through SSH for just such purposes. I just don't remember what it is... ...yet! |
| gus3 Mar 01, 2011 8:08 PM EDT |
It probably involves magically turning UDP into TCP, using iptables or some such. Probably about as painful as making IP work via carrier pigeon. Maybe this is what you're thinking of, Bob? |
| Bob_Robertson Mar 01, 2011 8:52 PM EDT |
Ok, Gus, that's pretty much what I was remembering, maybe just establishing an encrypted VPN is easier. Carrier pigeon looks easier, too, but as I remember the retransmit time for lost pigeons was killer. |
| jimbauwens Mar 02, 2011 6:42 AM EDT |
XDMCP is fun, and I use it allot. You can use it with Xnest, which will put the session in a window. It is as simple as running : Xnest :10 -query other_computer_name_or_ip . Of course you need XDMCP enabled on your client (the computer that you want to connect to). |
| Bob_Robertson Mar 02, 2011 7:11 AM EDT |
Well, I finished up my own "ssh primer", but I'm going to wait a day or two before putting it out, because I don't want to over-use LXer's welcome. I dunno, should i put it up and let folks debug it a bit and then submit it? This whole blog thing is crazy. Never quite sure what anyone else might be interested in, and since I don't have anyone to please but myself I try to do things I'd like to see. "But it's all right now, I've learned my lesson well. You see, you can't please everyone so you've got to please yourself." |
| gus3 Mar 02, 2011 6:05 PM EDT |
On the blog topic: Tech drives views (according to one of our own, who should know). I was going to take down all the non-tech stuff on my blog, until someone searched for a non-English phrase and found the article I wrote about it. After that, I think I can leave the other stuff up. |
| Bob_Robertson Mar 02, 2011 8:44 PM EDT |
Gus, It's not like it takes up all that much space. I just don't want to talk about my non-tech life right now. It hurts too much. |
| cr Mar 03, 2011 12:29 AM EDT |
@bob:Quoting: Cr, I do understand, but I don't OWN a scope, nor does anyone I know in this Cromm-forsaken burg. Not even any nearby hams? Bummer. Found on web: How to Use Your Sound Card as an Oscilloscope For more, google "sound card oscilloscope". The signals you're looking for are mostly well within the audio range. On my older equipment that runs Gnome1-compatible distros, I've found gnoise to be a nice WAV editor/displayer, if it comes to that. Or: hang a long-timeconstant RC network (say, 1Kohm to the rail, and 2200 uF paralleled with 0.1 uF ceramic, to ground... Maybe build that into an empty plastic soap-box with banana jacks for longterm test adapter use) off the rail you're about to test, in parallel with the real working load. Touch the RC junction with the DVM's return probe, touch the direct power rail with the hot probe, wait until the differential DC voltage across the resistor is about zero, then switch the meter to AC volts. Now you're looking at the AC riding on that DC rail, and it should be low-to-nothing at that DVM's sample-rate (ignoring switching transients because I think they'll be integrated out). Start with the lowest rail, stepping through to the highest, to save time and hassle (because, built as described, other than that series resistor that cap only has its own leakage for a discharge path, so it'll hold whatever charge the last rail put on it). You don't want to muddy the test by putting a higher voltage onto the rail. That AE cap should have a working voltage of 1.5+ times the highest voltage you'll test (because you're actively looking for overvoltage conditions). The resistor can be a quarter-watt (it's only seeing 0.144 watt dissipation at 12v), or a half-watt if you want physical strength. Quoting: It looks like Cr said that it automagically came up from his RedHat 6.1 system. Could be it was turned on by default, RedHat being a "server" kind of install. Nope, that was me fumbling around over the last decade trying to get my kitchen machine (hel) to run an X session off of my main server (demonhouse). I was surprised when mjolnr, my younger son's Mepis6.5 machine, picked up the DMCP offer after my many failed tries to make it work redhat-to-redhat. Maybe sometime I'll do a vanilla RHL6.2 install, then file-compare to see if I can zero in on what I altered, other than the xdm-config line noted in the earlier post. Or put that crossover cable to use as described, as I do think it might be a firewall issue. @jim: are you running ipv6 on your LAN? Xnest on both boxes given a quick try here failed with complaints about inet6, which is why I ask. (If not I'll go RTFM like I shoulda.) Edit: "sound card" is two words in the google bar. |
| caitlyn Mar 04, 2011 10:12 PM EDT |
Bob, your original command: ~$ ssh -Y bob@10.2.3.4 will only work if your local machine permits a remote X host to display. I keep my security pretty darned tight and, increasingly, a lot of distros do by default. For that to work I do need to type in ~$ xhost + 10.2.3.4 first. Otherwise the X session will be blocked. |
| Bob_Robertson Mar 05, 2011 9:34 AM EDT |
Caitlyn, No, it works just fine. That's what -Y does, bypass security. If I try to open up a display without -Y, you're right, it fails unless I use xhost. The entire point of -Y is that it works without making that security hole. |
| gus3 Mar 07, 2011 2:06 PM EDT |
Hmmm, I see a conflict of assumptions here. Bob, you're right that -Y bypasses the SECURITY extension of the X server, which then permits remote clients to use Mesa and other "we're not sure how secure these are" extensions. These are all forwarded through the SSH session, which means that an X client program running on the remote system with the OpenSSH server, can communicate through the SSH client with the local X server. However, that must be enabled in /etc/ssh/sshd_config's "ForwardX11" setting, either by default or by the admin. Caitlyn, you are also right, in that an OpenSSH server configured not to forward X connections, can be bypassed by a remote X client, and communicate with the local X server directly through TCP/IP. However, the local X server must be informed that a remote system may be running a client that wishes to talk to it. Two different scenarios, two different results. Does that make sense? |
| Bob_Robertson Mar 07, 2011 3:03 PM EDT |
> Two different scenarios, two different results. Does that make sense? No! Absolutely not! If Caitlyn is ever right about anything my entire world view will collapse and I would instantly die as the world turned upside-down and I was locked in liquid rock as the surface descended into the lower mantle. Nyaa. |
| gus3 Mar 07, 2011 4:43 PM EDT |
So that's a "yes" from Bob. Caitlyn? |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!