X forwarding for the conceptually challenged
May 10, 2015 10:04 PM Subscribe
I need to X forward remotely from outside a private Linux network to display onto a Windows 8 laptop.
The challenge: I know next to nothing about computer networking. Also, the Linux administrator for the remote network will absolutely not change "ForwardX11 no" to yes in my ssh_config file under any circumstances. I am stuck working around this.
I have MobaXterm installed on Windows 8. So, how can I trick Linux into displaying X on my remote Windows laptop without X forwarding enabled on my ssh config file in the private network? The more explicit the instructions, the better. I think I may need to set up an ssh tunnel(?) through MobaXterm but do I want local port forwarding? Remote port forwarding? a VPN? If so, how to set that up? Please help!
The challenge: I know next to nothing about computer networking. Also, the Linux administrator for the remote network will absolutely not change "ForwardX11 no" to yes in my ssh_config file under any circumstances. I am stuck working around this.
I have MobaXterm installed on Windows 8. So, how can I trick Linux into displaying X on my remote Windows laptop without X forwarding enabled on my ssh config file in the private network? The more explicit the instructions, the better. I think I may need to set up an ssh tunnel(?) through MobaXterm but do I want local port forwarding? Remote port forwarding? a VPN? If so, how to set that up? Please help!
You should consider whether any of the workarounds you're considering would be likely to upset your Linux administrator even more than having "ForwardX11 yes" would. Most of the administrators I know would have a minor heart attack over the idea of a rogue VPN server, for example. Could you explain a bit more about what you're trying to do, and why? What else is the Linux machine you're logging into doing? Is it a workstation or a server? Do other people use that machine? What application are you running? There are probably many ways to achieve what you want but which one is best depends on the details.
X communicates over TCP; the first X server on a machine usually listens on TCP port 6000, and is known to X as :0; the second X server uses port 6001 and is known to X as :1, and so on. So what you want to do is forward some port around but above 6000 on the remote machine to port 6000 on your machine. If you're doing ssh at the command-line, that would look something like "ssh -R 6001:127.0.0.1:6000", assuming you are using port 6001. The programs on the remote machine will then have to be told to connect to port 6001; you can do this by setting the DISPLAY environment variable to :1; you can do this by including it before whatever command you're running, like "DISPLAY=:1 /path/to/my/cool/program"
X also has a security mechanism that I don't entirely understand. If MobaXterm enforces that you're going to have to find some way to turn that off. Faking that mechanism out, and setting the DISPLAY variable for you, are most of the additional magic that go into SSH's X11 forwarding beyond simple TCP forwarding.
posted by jordemort at 11:28 PM on May 10, 2015 [1 favorite]
X communicates over TCP; the first X server on a machine usually listens on TCP port 6000, and is known to X as :0; the second X server uses port 6001 and is known to X as :1, and so on. So what you want to do is forward some port around but above 6000 on the remote machine to port 6000 on your machine. If you're doing ssh at the command-line, that would look something like "ssh -R 6001:127.0.0.1:6000", assuming you are using port 6001. The programs on the remote machine will then have to be told to connect to port 6001; you can do this by setting the DISPLAY environment variable to :1; you can do this by including it before whatever command you're running, like "DISPLAY=:1 /path/to/my/cool/program"
X also has a security mechanism that I don't entirely understand. If MobaXterm enforces that you're going to have to find some way to turn that off. Faking that mechanism out, and setting the DISPLAY variable for you, are most of the additional magic that go into SSH's X11 forwarding beyond simple TCP forwarding.
posted by jordemort at 11:28 PM on May 10, 2015 [1 favorite]
You’re going to have to tell us what exactly it is you’re trying to achieve before anyone can really help you.
However, if the sysadmin of the remote network is unwilling to turn on ssh X forwarding then opening up a direct unencrypted X connection is going to give them conniptions of a different order entirely.
posted by pharm at 2:34 AM on May 11, 2015
However, if the sysadmin of the remote network is unwilling to turn on ssh X forwarding then opening up a direct unencrypted X connection is going to give them conniptions of a different order entirely.
posted by pharm at 2:34 AM on May 11, 2015
> Also, the Linux administrator for the remote network will absolutely not change "ForwardX11 no" to yes in my ssh_config file under any circumstances.
If admin won't change it because she/he's concerned about sending X connections out over a private link to an untrusted computer, imagine the shitstorm that's coming when the admin discovers you're sending X connections out over a public, unencrypted link to an untrusted computer.
Maybe you don't need the admin to change things. I'm not sure of the config application order. The "ForwardX11" sets the *default* state, but may not disable forwarding. It's not on by default, but that doesn't mean you can't turn it on by asking from your end. In linux client land, that's "ssh -X ...." .
posted by cmiller at 5:59 AM on May 11, 2015
If admin won't change it because she/he's concerned about sending X connections out over a private link to an untrusted computer, imagine the shitstorm that's coming when the admin discovers you're sending X connections out over a public, unencrypted link to an untrusted computer.
Maybe you don't need the admin to change things. I'm not sure of the config application order. The "ForwardX11" sets the *default* state, but may not disable forwarding. It's not on by default, but that doesn't mean you can't turn it on by asking from your end. In linux client land, that's "ssh -X ...." .
posted by cmiller at 5:59 AM on May 11, 2015
What cmiller said - and in addition the ForwardX11 (or -X) option should be invoked on the _client_ side, not on the remote Linux machine . I would guess mobaXterm handles that stuff out of the box.
That being said, there's a bunch of other stuff that needs to be enabled on the remote side (maybe your sysadmin has AllowTcpForwarding set to no) in which case there's not much you can do.
posted by Dr Dracator at 6:28 AM on May 11, 2015
That being said, there's a bunch of other stuff that needs to be enabled on the remote side (maybe your sysadmin has AllowTcpForwarding set to no) in which case there's not much you can do.
posted by Dr Dracator at 6:28 AM on May 11, 2015
Your admin allows direct SSH connections from the internet but won't allow X11 to be tunneled over it? That seems ... atypical. The ssh is securing whatever traffic you put over it, there's not really a strong argument for limiting what you put through the tunnel in my mind.
I'm rather confident that if X11 forwarding is disallowed by either your personal ssh_config on your client (which is non-writeable to you? That also seems weird) or in the remote host system's sshd_config (which is probably the element out of your control that actually is in your way right now), you cannot tunnel X11 over SSH to that host no matter what you do.
As Dr Dracator writes, in addition to controlling the availability of explicit X11 forwarding, the server admin can also allow/disallow TCP forwarding of any kind. It's pretty likely they would have both of these off together, in which case you're sunk.
Can the admin offer any other access mechanism for you? Maybe they already have a VPN running you can use to use X11 or VNC direct after getting on their VPN?
DO NOT SET UP A ROGUE VPN SERVICE PLEASE OMG THEY WILL BURN YOU
One long shot option: If the admin at least allows non-X11 TCP forwarding AND the remote host has a VNC server installed (try 'which vncserver' or 'which vnc4server' in an SSH terminal connection, and if it returns a path with such a name at the end, then it's installed), you could tunnel a VNC desktop session over SSH. That all happens in userland and needs no further permissions from your admin. If the 'which' commands above produce nothing found, then it's not installed and of course you could not install it yourself, but you could ask your admin if it might be possible to add that to the host.
Using VNC over SSH should be googleable, sorry I don't have the cycles to find a clear link or otherwise document that right now. You would also need a VNC client program for Windows, several of which exist for free. Others may have advice on that front.
If the political aspect of getting access to the Linux environment remotely is too large an obstacle, do you have a manager who can talk to the admin, or as a last resort to the admin's manager? Making the business case at that level may help them change policy to support you better.
Good luck!
posted by BlackPebble at 7:41 AM on May 11, 2015
I'm rather confident that if X11 forwarding is disallowed by either your personal ssh_config on your client (which is non-writeable to you? That also seems weird) or in the remote host system's sshd_config (which is probably the element out of your control that actually is in your way right now), you cannot tunnel X11 over SSH to that host no matter what you do.
As Dr Dracator writes, in addition to controlling the availability of explicit X11 forwarding, the server admin can also allow/disallow TCP forwarding of any kind. It's pretty likely they would have both of these off together, in which case you're sunk.
Can the admin offer any other access mechanism for you? Maybe they already have a VPN running you can use to use X11 or VNC direct after getting on their VPN?
DO NOT SET UP A ROGUE VPN SERVICE PLEASE OMG THEY WILL BURN YOU
One long shot option: If the admin at least allows non-X11 TCP forwarding AND the remote host has a VNC server installed (try 'which vncserver' or 'which vnc4server' in an SSH terminal connection, and if it returns a path with such a name at the end, then it's installed), you could tunnel a VNC desktop session over SSH. That all happens in userland and needs no further permissions from your admin. If the 'which' commands above produce nothing found, then it's not installed and of course you could not install it yourself, but you could ask your admin if it might be possible to add that to the host.
Using VNC over SSH should be googleable, sorry I don't have the cycles to find a clear link or otherwise document that right now. You would also need a VNC client program for Windows, several of which exist for free. Others may have advice on that front.
If the political aspect of getting access to the Linux environment remotely is too large an obstacle, do you have a manager who can talk to the admin, or as a last resort to the admin's manager? Making the business case at that level may help them change policy to support you better.
Good luck!
posted by BlackPebble at 7:41 AM on May 11, 2015
This thread is closed to new comments.
posted by vixsomnis at 10:49 PM on May 10, 2015