[Bdi4emc-help] consequences of newer OpenSSH on remote X11 displays

[bdi4emc-help at lists.ourproject.org]

Gentle persons:

This note applies if you are running BDI-4.30 (see footnote) and want to 
run EMC or other X11 applications through a secure ssh channel from 
another computer.

For example, I have my BDI-host in a basement utility room and sometimes 
want to run X11 applications (including EMC in simulation mode) on it 
from a Windows host in my office or a Linux (sometimes Red Hat, 
sometimes Fedora Core) host in my rec room. These hosts are 
interconnected via wired and wireless ethernet.

The Debian distribution that is part of BDI-4.30 includes version 3.8 of 
OpenSSH compared to version 3.6 on my other Linux hosts (but version 4.2 
in my up-to-date Cygwin installation on my Windows host).

With this newer version, the OpenSSH folks changed the configuration so 
that X11Fowarding is disabled by default (for security reasons). Thus, 
connecting to my BDI-host from another box using the shell command "ssh 
-X bdi_ip_or_hostname" and then invoking an X11 application on the 
BDI-box, e.g., xeyes, will result in an error message instead of causing 
a new X window (with the xeyes "eyes" for example) to open on my local 
host as I have come to expect.

A remedy is to edit the /etc/ssh/sshd_config file on the BDI host to 
enable X11Forwarding (change the line "X11Forwarding no" to 
"X11Forwarding yes") and then restart sshd (for example, from the 
console, find the sshd process identification pid using ps -ax and send 
it a hangup signal, "kill -HUP pid") to force it to reread its 
configuration file. Now simple X11 applications like xeyes and xclock 
will open new windows fresh as paint.

However, newer versions of OpenSSH also differentiate between untrusted 
and trusted X11 clients and consider all clients to be untrustworthy by 
default. It turns out that both EMC and EMC2 try to read information 
from the X11 server in a manner which isn't permitted of an untrusted 
X11 client. Hence, with my CygwinX installation, I have to invoke ssh 
with the -Y option rather than the -X option to create a secure channel 
that will work with EMC. (This -Y option doesn't exist in older versions 
of OpenSSH.) I'm still figuring out how to force behavior equivalent to 
-Y using configuration or environment settings. (From the amount of 
whinging I've seen on various mail lists and boards, this isn't a 
problem only with EMC, so you may well find you have other X11 
applications that fail to run properly as untrusted clients.)

Note that one can avoid all this by running X11 using the insecure X11 
communications protocol just as MIT designed it (strongly not 
recommended unless all the hosts involved are behind a *really* good 
firewall; sooner or later the bad guys find every crack!). To set this 
up, one does things the old-fashioned way

1. on the local host, declare the remote host to be trusted by the local 
X11 server: "xhost +bdi_ip_address/bdi_hostname"
2. ssh to the remote host
3. on the remote host, set the DISPLAY environment variable to point to 
the local host's X11 server. The syntax for this varies with the shell 
in use. In the bash shell, one can invoke "export 
DISPLAY=the_remote_ip_or_hostname:0.0". Note that it is commonplace to 
assume that the display number will be 0.0, and it usually will be, but 
it should always be confirmed for the X11 server in question.

Steps 1 and 3 are totally unnecessary when X11 forwarding via ssh is 
working.

Regards,
Kent

footnote: this note may apply to previous versions of the BDI but I 
don't have them and can't say.