Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

X Login via XDMCP over an SSH tunnel UNIX
If you ever wanted to log into a Unix system via X11 as if you were sitting in front of it with a monitor connected to it, you aren't out of luck. Unfortunately X11, the protocol used for this, wasn't designed to be the most secure of environments. But that's where SSH tunneling comes in.

Many people know you can tunnel insecure traffic over a secure SSH connection, and some people even know you can do this with X-Windows traffic as well. But in case anyone out there doesn't know, you can actually create an entire X11 session, with everything from login to using your favorite window manager, securely over SSH as well.

Here's the procedure I use to start an X Login session remotely to a system over an SSH tunnel:
  1. Make sure X11 forwarding is enabled on the remote system's sshd configuration -- see note #1.

  2. Run ssh -X remote.host -- you would run this in Terminal.app; the -X enables X11 forwarding.

  3. Once logged in, at the remote host's prompt, type Xnest :1 -geometry 1280x810 -query localhost -- this will start an empty nested X window on the default display $DISPLAY the size of -geometry and fill it with an xdmcp query of localhost.
Notes:
  1. If X11 forwarding is being done properly, once you're logged into the remote system, typing echo $DISPLAY should show the workstation's X-server's X11 display environment variable (which goes over the SSH tunnel). If this doesn't show up, then X11 forwarding isn't working properly.

  2. The 1280x810 dimensions are appropriate to (almost) fill up a 15" PowerBook's screen. Adjust as necessary if you don't have the same resolution screen.

  3. If the login window fonts are screwy (e.g., the login box is cut off by the logo) or if your login session is reset (you're kicked back to the login window), you may not have the appropriate fonts set up on your (workstation's) X server. To fix this, run this before running Xnest:
    xset +fp tcp/ip.of.the.srv:7100
    This assumes that the X font server is running on port 7100, and that the remote system has a reachable IP address (aka no NAT from the server and you (from you to server is OK, though)). This is necessary on some workstation's X servers to connect to the system and download any fonts that it doesn't have that it needs to render/login properly.

  4. For the really clever, you can just run one ssh command by passing the entire Xnest command along to be executed when you log in. But you may need to specify the absolute path to Xnest if it's not in the system's default search $PATH.
Lastly, I want to thank the people in a previous hint who helped me discover Xnest on OS X and its plethora of options. When I realized Xnest was on other Unix's, that's when I knew I could really "go to town" with it over ssh tunnels.
    •    
  • Currently 2.29 / 5
  You rated: 3 / 5 (7 votes cast)
 
[79,278 views]  

X Login via XDMCP over an SSH tunnel | 12 comments | Create New Account
Click here to return to the 'X Login via XDMCP over an SSH tunnel' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
X Login via XDMCP over an SSH tunnel
Authored by: joshewah on Nov 19, '04 01:27:45PM
You can also run specific apps as needed like xterm or firefox etcl. that reside on the host machine instead of running the entire X session by using those commands instead of Xnest.

One snag I have run into is if you echo $DISPLAY from Terminal.app it returns nothing even if you set $DISPLAY to :0.0 like it should be. You will get something like "xterm Xt error: Can't open display: " from the remote machine. You can get around this one of two ways.

1. Add `DISPLAY=:0.0` before the ssh command. Example: DISPLAY=:0.0 ssh somehost.com

2. Run ssh from within X11's xterm.

If somebody could fill me in on the difference between how Terminal.app and X11's xterm starts up environment wise that explains why this is happening that would be great :)

[ Reply to This | # ]
X Login via XDMCP over an SSH tunnel
Authored by: EddEdmondson on Nov 19, '04 07:07:11PM
Only children of X11.app will get the DISPLAY variable passed down to it. Terminal.app won't because it isn't a descendent of the X11.app.

Two solutions:
1) Use X11.app to open the terminal process - either using 'open -a Terminal' from an xterm or perhaps from the menu. Then it will correctly inherit the DISPLAY setting. Terminal.app must not be running already when you do this however.
2) Use a suitable script to determine the DISPLAY variable correctly.

Do not set DISPLAY to :0.0 manually or in a script. There is no guarantee that that is the correct value. It can be higher if there is already a lower-numbered X-server running on the machine. Example: start X11.app then fast-user-switch to another user and start X11.app there too. The second user will have DISPLAY of :1.0 instead.

[ Reply to This | # ]

X Login via XDMCP over an SSH tunnel
Authored by: gdsimms on Nov 19, '04 01:37:44PM

Or, from the terminal:

X -once -query myremotexhost.domain.tld



[ Reply to This | # ]
X Login via XDMCP over an SSH tunnel
Authored by: gdsimms on Nov 19, '04 01:39:40PM

Oops. Hint was about ssh, not just XDMCP. Duh.



[ Reply to This | # ]
X Login via XDMCP over an SSH tunnel
Authored by: waffffffle on Nov 19, '04 02:05:54PM

This gives me a blue window. How do I get a login screen? I am trying to connect to a computer running Mandrake 10.1. I had to urpmi Xnest to get this far.

Thanks.



[ Reply to This | # ]
X Login via XDMCP over an SSH tunnel
Authored by: maddys_daddy on Nov 19, '04 02:33:01PM

I get the same blue window, with the default "X" X11 cursor.
Any ideas?



[ Reply to This | # ]
X Login via XDMCP over an SSH tunnel
Authored by: cynikal on Nov 19, '04 05:57:29PM

the blue screen likely means you can connect, but an xdmcp agent may not be running out-of-the-box.. if you couldn't connect at all, you'd likely just get an entire gray screen instead of even blue (unless blue is that system's default color). you may want to run a port scanner on your udp port 177 to check if there's an xdmcp daemon listening on that port.



[ Reply to This | # ]
X Login via XDMCP over anything !
Authored by: mounty on Nov 19, '04 05:47:30PM

I'd just like the apparently more simple, but still unachievable (to me) functionality of having MacOSX's server issue an XDMCP on startup to another machine, and thereby having the remote machine starting an XDM session on it . . .

If anyone can point me to this, I'd be most grateful.



[ Reply to This | # ]
X Login via XDMCP over anything !
Authored by: RiotNrrrd on Nov 21, '04 09:46:13PM
eXodus 9.0 can do this with ease. It's got really nice XDMCP (not to mention SSH) support. (Unfortunately, it doesn't have Apple's really nicely accelerated Xquartz server, so I don't use eXodus anymore.)

XDMCP/XDM support (or lack thereof) is really one of the major weaknesses of Apple's X11.app compared to other X11 implementations, whether they be on other Unices/Linux or other Mac-based products such as eXodus.

Something else that stinks - it seems like Apple likes to drop things from 3rd-party releases that are still useful, even on a Mac. The 10.3 version of X11.app drops a lot of documentation - in /usr/X11R6/lib/X11/doc there's only a bunch of HTML files (in .../html) now - compared to, say, XDarwin 1.1, where there used to be a whole raft of stuff, including XDMCP documentation:

[18:07] pb17:/Previous Systems/Previous System 1 % ls usr/X11R6/lib/X11/doc
usr/X11R6/lib/X11/doc:
BUILD README.isc html/
BugReport README.mouse i18nFramework.TXT
DESIGN README.newport icccm.TXT
DPMS.TXT README.r128 ice.TXT
DPMSLib.TXT README.rapidaccess index
ICElib.TXT README.rendition intrinsics.TXT
INSTALL-X.org.TXT README.s3virge libGL.TXT
Install RELNOTES mit-shm.TXT
LICENSE RELNOTES-X.org.TXT overview_xie.TXT
LocaleDB.TXT SMlib.TXT proto.TXT
OS2.Notes ServersOnly record.TXT
PM_spec.TXT Status recordlib.TXT
PostScript/ Versions render-protocol.TXT
README VideoBoard98 rstart.TXT
README.DECtga XIEProto.TXT rstartd.TXT
README.DGA XIMTransport.TXT shape.TXT
README.DRI XiLib.TXT shapelib.TXT
README.DRIcomp XiPorting.TXT tog-cup.TXT
README.Darwin XiProtocol.TXT widgets.TXT
README.I128 Xtrans.TXT xc-misc.TXT
README.LynxOS XvMC_API.TXT xdmcp.TXT
README.NetBSD appgroup.TXT xfs-design.TXT
README.OpenBSD bdf.TXT xieSIarch.TXT
README.SiS bigreq.TXT xielib.TXT
README.apm buffer.TXT xim.TXT
README.ati cmatch_xie.TXT xlfd.TXT
README.chips ctext.TXT xlib.TXT
README.cyrix ctlseqs.TXT xmu.TXT
README.dps ddx.TXT xsmp.TXT
README.fonts evi.TXT xtest.TXT
README.i740 fontlib.TXT xtestlib.TXT
README.i810 fsproto.TXT xv-protocol-v2.TXT

[18:08] pb17:/Previous Systems/Previous System 1 % ls -l usr/X11R6/lib/X11/doc/PostScript/xdmcp.PS
-r--r--r-- 1 root unknown 96238 18 Jan 2002 usr/X11R6/lib/X11/doc/PostScript/xdmcp.PS

I have no clue why Apple dumped all this documentation when they released their own version of XFree86 4.3.0 in X11.app.

(That said, doing XDM is still tricky - even if you read the xdm(1) man page and get it fired up properly on your remote Mac, there are still gotchas - one gotcha I can recall is trying to connect to an XDM server at work over our VPN, but finding that the remote XDM server was trying to route the return packets to the original local IP address rather than the VPN-assigned local address, which wasn't working - we were blocking all outbound connections to port 6000 with a destination IP address outside of our Class B address space. Apparently the XDMCP packets being sent from the local end were tagged with the "real" IP address instead of the VPN-assigned local address. So the return packets went off to never-never land and the XDM connection failed ... )

[ Reply to This | # ]

X Login via XDMCP over an SSH tunnel
Authored by: smuggi on Nov 22, '04 04:31:05PM

Hi, What I have to do if I have "double" ssh tunnel? Could anobody help me?



[ Reply to This | # ]
X Login via XDMCP over an SSH tunnel
Authored by: avramd on Aug 08, '05 12:18:58PM

Can anyone help me get the "xset +fp..." command working? When I try to issue this command, I get:

xset: bad font path element (#87), possible causes are:
Directory does not exist or has wrong permissions
Directory missing fonts.dir
Incorrect font server address or syntax

From the instructions, my understanding is that this command is to be run in the ssh session, and the IP I give it should be the IP address of the machine I'm connecting from (i.e. my Mac).

also, how does one determine what port one's font server is running on? My Mac does not accept connections on port 7100. It is listening on the remote machine, but if he wanted us to connect to that machine, then he shoudl have just used 127.0.0.1 as the IP...



[ Reply to This | # ]
X Login via XDMCP over an SSH tunnel
Authored by: avramd on Aug 16, '05 01:12:54PM

Just thought I would let you all know I answered my own question; Here is what you have to do to fix the font problem. Note that this goes beyond what this person is suggesting, by solving the VPN/Firewall problem too.

When you ssh to the remote server, forward local port 7100 to the remote host. Then in another window, on your mac, add localhost:7100 to the font path. After tha, back on the remote host, use the Xnest command to start up the desktop session. Here's what it looks like:

mac% ssh -L7100:localhost:7100 -Y user@remotehost

(in another window)
mac% xset +fp tcp/localhost:7100

(back in the first window)
solaris% Xnest ":1" -geometry 1280x810 -query localhost



[ Reply to This | # ]