David Thompson:
|The problem was not giving the full path to ssh.
Glad you found it. That makes sense.
|I've updated the code in autoconf to find rsh as you can see from all
|the new commits I just made.
Thanks. I'll do a CVS pull tonight and try it out.
|One question to those that have used this in the past.
...
|2) Enable remote X on client (xhost + servername)
...
|My question to those in the know, did you always have to do step 2? I
|can't remember. Now with new code, you can:
|
|1) On Client setenv DXRSH /usr/bin/ssh
|2) Make sure ssh works without password (enable Rhosts/Shosts and make
.shosts)
|3) Follow steps 2-5 above.
It sounds like you might be using ssh's X forwarding feature. If enabled
(usually is by default) then ssh sets up a tunneled X connection from the
remote end to the local end. The virtual display on the remote end usually
starting numbering up from 10 -- i.e. port 6010), so echo $DISPLAY in the
remote shell will read "<remotehost>:10.0" or something similar.
Since it's tunneled through ssh and sent to your local display by a local
ssh client running as you, it piggy-backs on your X display access on the
local machine, and no xhost/MIT-MAGIC-COOKIE tricks are needed to grant
remote X clients running in the ssh shell access to write to your local
display. Also, the X stream is encrypted and compressed (if enabled) along
with the rest of your shell data.
One con is that this compression and/or encryption and forwarding of your
X data stream slows down remote X clients alot on a fast LAN. I use ssh to
connect to some local LAN hosts, but override $DISPLAY in my .cshrc to
point directly back to my machine's :0 display for faster display.
Another con is having to explicitly grant the remote X server access to
talk to the local display through traditional means: xhost (more insecure)
or MIT-MAGIC-COOKIE/xauth (less insecure). I've attached a version of an
"xallow" script that floats around here to make the latter approach easier.
To configure, set $MYDOMAIN up top. Then to use: "xallow host", "xallow
[EMAIL PROTECTED]" for rsh connects. Append "ssh" as a second argument for ssh
connects.
|What would be nice would be to have the executive pass the XDisplay
|back over the ssh socket. I messed with it a bunch but can't get it
|to work as is.
Well one of the problems is (with execution groups at least), rsh/ssh is
only used to connect over to the remote end, create a shell script in /tmp
that invokes a dxexec, and invoke that script. The shell script is created
to set dxexec's $DISPLAY to <localhost>:0.0 (all this was there before; I
just updated it to make <localhost> a FQDN). So, when the script is
invoked, this bypasses any ssh X forwarding that might have been set up
(e.g. <remotehost>:10.0), and requires that xhost or xauto be used to
grant X display access to the remote system.
|What inherent security risks are there by allowing remote X to display on
|the client?
With xhost (more insecure), any user on the xhost-allowed systems can
connect to your X display and see everyting you're doing (typing passwords,
writing e-mails, etc.) as well as run X clients to display on your screen.
With xauth (more secure), only users which have been given a copy of your X
session's cookie (MIT-MAGIC-COOKIE -- see "xauth list") can write to your
display. So if you pass your cookie over to a remote login, and it's
stored in ~/.Xauthority with permissions to only be readable by you, only
you on the remote system (**) can use that cookie to connect to your X
display.
** Caveat: Anyone who has root access to your remote or local $HOME can of
course read your ~/.Xauthority, grab your cookie, and access your display.
So if you have questionable or unscrupulous remote admins, ssh X forwarding
might be the way to go.
If we wanted to handle X permission passing under the hood as you suggest,
we could have another option added to dxui connect GUIs and DX connect APIs
to specify whether the X display cookie would be passed across the net (via
xauth | rsh/ssh xauth) before invoking the remote dxexec. This could be
deselected for those that choose to use ssh X forwarding and don't need the
cookie passed.
Randy
--
Randall Hopper (mailto:[EMAIL PROTECTED])
Lockheed Martin Operation Support
EPA Scientific Visualization Center
US EPA MD/24 ERC-1A; RTP, NC 27711
#! /bin/sh --
#
# Script to authorize a remote user and machine to your display.
#
MYDOMAIN="internal.internet.com"
PROGNAME=`basename ${0}`
MYFQDN=`hostname | cut -f1 -d.`.${MYDOMAIN}
XUSER=""
USAGE="usage: ${PROGNAME} { host | [EMAIL PROTECTED] } [<rsh_client>]"
RPATH="/usr/bin/X11:/usr/openwin/bin"
if [ $# -lt 1 -o $# -gt 2 ]
then
echo ${USAGE} 1>&2
exit 1
elif [ `expr $1 : '.*@'` -ne 0 ]
then
MACHINE=`expr $1 : '[EMAIL PROTECTED](.*\)'`
XUSER=" -l `expr $1 : '\([EMAIL PROTECTED])'`"
else
MACHINE=$1
fi
if [ $# -eq 2 ]; then
RCMD="$2"
else
RCMD="rsh"
fi
case "$DISPLAY" in
"localhost:0" | ":0" | ":0.0" | "unix:0" | "unix:0.0" )
DISPLAY=${MYFQDN}:0;;
esac
case "$MACHINE" in
weirdhost1) RPATH="/usr/bin/X11:/usr/local/bin";;
weirdhost2) RPATH="/usr/bin/X11:/usr/local/bin";;
esac
#/usr/bin/X11/xauth extract - $DISPLAY | \
# $RCMD ${MACHINE} ${XUSER} /usr/bin/X11/xauth merge -
xauth extract - $DISPLAY | \
$RCMD ${MACHINE} ${XUSER} env PATH=${RPATH} xauth merge -
