consequences of newer OpenSSH on remote X11 displays
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.
Hi Kent On Sunday 11 December 2005 23:19, [email protected] wrote:
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.
Thanks for the info - I think we (as a group) need to discuss a layout of the wiki so that little snippets such as this can be found quickly and easily. I have a couple of thoughts on the subject which I'll broach in another email.. Small side note: I think it may be Debian that changed the default for X11 forwarding. I've noted a few other packages have certain security risks disabled... This, I suspect, is probably do to Debian being more security conscious than some of the other distributions. Regards, Paul.
On Sunday 11 December 2005 18:19, [email protected] wrote:
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
Thanks Kent, this might be the blow by blow I need to get it working when I get things re-installed. My hd's got too cold and took a crap on me, so I've got to figure out a heater, and do a total mkext2 on everything & reinstall. -- Cheers, Gene People having trouble with vz bouncing email to me should use this address: <[email protected]> which bypasses vz's stupid bounce rules. I do use spamassassin too. :-) Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
Hi Gene Could you do all a favour and just quote the relevant content in a reply. This would be a great help in the future when people search the archives for specific answers. BTW - It also helps to change the "Subject" header when wandering off topic. Minor nit-picking to some, but long term, of great help when reading the archives - Possibly why so many nuggets of information are condemed to obscurity in the emc archives... Regards, Paul. On Monday 12 December 2005 01:33, [email protected] wrote:
message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
_______________________________________________ Bdi4emc-help mailing list
On Sunday 11 December 2005 23:19, [email protected] wrote:
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.
Steps 1 and 3 are totally unnecessary when X11 forwarding via ssh is working.
Distilled the info down to it's minimum and confirmed it works on a fresh BDI-4 install. I did notice that the setting of DISPLAY was not needed as the -X flag should automatically set the variable. Please feel free to pad out http://ourproject.org/moin/Remote_X_sessions if you think it is a little spartan or correct any mistakes. Regards, Paul.
participants (1)
-
bdi4emc-help＠lists.ourproject.org