Ssh – Running vim on a remote Linux machine “freezes” OS X SSH connection

A few notes from the GLX Wikipedia article:

GLX [is] An extension of the X protocol, which allows the client (the OpenGL application) to send 3D rendering commands to the X server (the software responsible for the display). The client and server software may run on different computers.

and

If client and server are running on the same computer and an accelerated 3D graphics card using a suitable driver is available, the former two components can be bypassed by DRI. In this case, the client application is then allowed to directly access the video hardware through several API layers.

I believe the fist point answers your question about whether this is possible or not: it should certainly be possible. The second may provide an explanation for why your client program insists on using features of its local X server (the NV GLX driver) -- perhaps it thinks that localhost:10.0 is the same computer, and so attempted a direction connection.

Things to try:

1. Instead of gazebo, try glxdemo.
2. If possible, get the two computers on the same network, and take ssh out of the picture
3. The big gun: strace your gazebo invocation, and figure out why it's loading nv-glx

Good luck!

If you are using a server-in-the-middle to interconnect two systems, chances are at least one of the lines is rather slow. In that case VNC is likely to give you better performance, since you can tune the bandwidth/performance requiremens/quality ratios better (this is actually valid for most setups, unless you are on a reliable 100Mbit+ network).

I personally like x11vnc, which connects to a running X server and forwards the inputs/output over the VNC protocol (this can be done as soon the X server is running, so you can interact even with a display manager). The X server in question can be both a regular one (which outputs to a real display) or a framebuffer based one like Xvfb. You can then use any VNC client to connect to the exported X server. And of course you probably want to tunnel the transmissionn through ssh or stunnel. The man page of x11vnc is quite exhaustive and even has a frequently used command line example at the beginning.

Ths also allows you to remotely connect to a running session to help somebody solve a problem remotely. As an important bonus, since just the inputs and output are forwarded rather than the X protocol itself, network disconnects will just interrupt the session, but all of the programs remain running, which is not the case of X through SSH.

If for some reason you really want to tunnel X11 through SSH, you must ensure that the DISPLAY environment variable is set up properly by ssh. Without it you can't proceed, because the applications won't know which server to connect to. Check whether the X11Forwarding directive is set to yes in your sshd configuration.

Last but not the least, you probably don't want to run startkde4 (or any other X session for that matter) over SSH - the network load will likely be quite heavy - VNC will serve you better again.