SUMMARY: remote CDE logins
From: Markus Waldorf (waldorfm_at_rferl.org)
Date: 06/12/03
- Previous message: Popovich, Tom: "If you are running release 4.0g can you run the following comman ds against your /usr/bin/passwd [resend with return email address]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 12 Jun 2003 11:39:21 +0200 To: Unix Managers <tru64-unix-managers@ornl.gov>
This mailing list has proven to be a very valuable resource of information
again, thanks to everyone who responded!
Below is a summary of replies I received. I hope someone else will find it
as useful as I do.
Answer received from Peter Stern:
It is a little difficult to understand exactky what you are doing here,
but if I understand correctly, you are mixing up the terminology of
client and server. What you call your workstation (merlin) is in fact
your Xserver and it is there that you need to run xhost + to allow
access by any client (e.g. xterm running on what you call your server).
In short, your "DISPLAY" is what is serving X to the X application
(client, e.g. xterm) you are running on it.
Answer received from J.A. Gutierrez:
xhost + will disable access control, so anyone can access your X server.
This means anyone can get a copy of your screen, snoop your keyboard, etc...
CDE/xdm login access is controled by an Xaccess file, usually
/etc/dt/config/Xaccess
xhost modifies the access list of current X server process.
Next time you start the Xserver (for instance by logging out)
the access list is reset.
You should not use xhost at all unless:
- You are in a private network
- Without non trusted users
xhost -> host based (usually). Any user on that host can get
access to your display. Is disabled by default.
xauth -> user based. Is enabled by default; xdm will create
the cookies when you log in your CDE session.
Answer received by Peter Wolfe:
Correct. xhost does not set things persistently. It's basically
calling the X11 apis: XSetAccessControl, XEnableAccessControl,
XDisableAccessControl, etc. These control the run-time behavior
of the X server.
dxhosts is a SysMan application that helps to make the xhost settings
persistent. If you run dxhosts at startup, then your "preferred hosts"
will automatically be ""xhost +hostname" for you.
Do you want an entire CDE login session from the remote machine
or just individual windows? For the entire session, you can start
the X server in -query mode. See the CDE Advanced User's and System Admin
Guide for details. Basically you do: X -query <remote host>
it makes the local X server act like an X terminal. You get
a session from the remote host. See the other XDCMP options
in this section of the docs as well.
See the Xsecurity man page for gory details but you have the gist of
it. Xhosts is user based access control and the other methods
are user-based. These methods use the .Xauthority file and the xauth
command. Unless you are really really concerned about security,
xauth and user based security is a PITA.
So is merlin the local Tru64 UNIX workstation? I assume yes. And you are
typing this command in a telnet session on the remote system (server). If
the local DISPLAY was set before the telnet, then telnet should have done
this for you. However, the missing piece is:
xhost +server_name
on a local window on the workstation. You need to authorize
the remote server system to send X11 traffic to the workstation....
Telnet DOES pass the local value of the DISPLAY variable to the remote side.
rlogin does NOT. I'm not sure about ssh. So you can get the automation
via telnet but other methods require that you set the DISPLAY environment
variable.
(What I experience is that SSH does create teh DISPLAY variable, Telnet does
not.)
Answer received from Bob Vickers:
Remote access using ssh is easy and secure, so you want to use this
rather than rlogin/telnet if possible. From the remote end type
ssh -X myserver
and ssh will sort out the DISPLAY variable and the magic cookie
authentication for you. You can then start any X client, e.g. xterm.
Answer received from Lucio Chiappetti:
However if you want a remote machine to be able to permanently access your
display, place its name in the file /etc/X0.hosts (or create it if not
existing).
Answer received from J.A. Gutierrez (continued...)
I don't understand exactly what you are trying to do. If you still want to
use xhost, it would go like this:
- Login at host_a from CDE
- Execute "xhost + host_b" at host_a
- Telnet from host_a to host_b
- su at host_b
- export DISPLAY=host_a:0 at host_b
- execute xterm at host_b
If you want to use xauth:
- Login at host_a from CDE
if [ using xjost ]
then
- execute xjost root@host_b
else
- execute at host_a
xauth extract - :0 > auth_file
- copy that auth_file to host_b
- (later) execute at host_b as root
xauth merge - < auth_file
fi
- Telnet from host_a to host_b
- su at host_b
- export DISPLAY=host_a:0 at host_b
- execute xterm at host_b
If you were using ssh, you only have to do:
- Login at host_a from CDE
- execute ssh -fX /usr/bin/X11/xterm
shorter and safer...
Regarding the DISPLAY variable:
You could automate this by
a) Using ssh instead. So you can forget about xhost, too
b) by using something similar to:
(very long, since it tries to be multiplatform, you could
trim it a lot)
---------------------------------------------------------------------------
#echo "##################### in .profile"
case `uname` in
OSF1)
ARCH=osf-alpha
;;
SunOS)
ARCH=sunos-`arch`
LC_CTYPE=iso_8859_1; export LC_CTYPE
;;
Linux)
ARCH=linux-`arch`
;;
IRIX*)
ARCH=irix-mips
;;
Darwin*)
ARCH=darwin-`arch`
;;
HP-UX)
if /bin/hp-mc680x0
then
ARCH=hpux-68k
else
ARCH=hpux-hppa
fi
;;
*)
echo Warning: unsupported system
;;
esac
[...]
#############
#
# who am i
#
if [ ${DISPLAY:-setdisplay} = setdisplay ]
then
# irix sets REMOTEHOST
if [ ${REMOTEHOST:-islocal} != islocal ]
then
DISPLAY=${REMOTEHOST}:0
else
if [ "${SSH_CLIENT:-notssh}" != "notssh" ]
then
echo "Warning: using ssh w/o X11 fwd"
DISPLAY=`echo "$SSH_CLIENT" | sed -e 's/ .*/:0.0/'`
else
echo "Warning: using clear unencrypted X11"
# Try to guess DISPLAY
case $ARCH in
sunos-sun4|osf-alpha)
TTY=`tty | sed 's:/dev/::'`
DISPLAY=`who am i | grep $TTY | tail -1 | \
sed -e 's/.*(//' -e 's/[\.)].*//'`:0.0
;;
irix-mips)
DISPLAY=:0.0
;;
hpux-*)
DISPLAY=`who am i -TR | awk '{print $9}'| awk -F: '{print
$1}'`:0.0
;;
*)
DISPLAY=`who am i | sed -e 's/^.*(//' -e 's/[:)].*//'`:0.0
;;
esac
expr "$DISPLAY" : ".* .*" >/dev/null 2>&1 && DISPLAY=":0.0"
# something went wrong, DISPLAY coultn't be guessed
fi
fi
export DISPLAY
fi
---------------------------------------------------------------------------
You don't want to use xhost.
xauth is better; it works with MIT-MAGIC-COOKIE-1. If you don't
use ssh and you want to grant access permissions using cookies
(a much better idea than xhost, since xhost gives (weak) access
control based on IP, and cookies grant access to individual users)
you could use some sort of script similar to this one:
- /usr/local/bin/xjost ----------------------------------------------------
#!/bin/sh
#
# SPDsoft 05/10/1995
# SPDsoft Dec 98; ssh
#
# Replacement for xhost(1) when using MIT-MAGIC-COOKIE-1
#
CMD=`basename $0`
usage()
{
echo "Usage: $CMD [-s] [user@]host"
echo "-s: Use ssh"
echo "-q: Quiet"
exit 1
}
set -- `getopt sqh $*`
if [ $? != 0 ]
then
usage
fi
if [ -z "$RSH_CLIENT" ]
then
if test -x /usr/bin/remsh
then
RSH_CLIENT=/usr/bin/remsh
else
RSH_CLIENT=rsh
fi
fi
QUIET=false;
for i in $*
do
case $i in
-s) RSH_CLIENT="ssh -x"; shift;;
-q) QUIET=true; shift;;
-h) usage; shift;;
--) shift; break;;
esac
done
if [ "$1" = "" ]
then
usage
fi
execho()
{
if ( $QUIET ); then : ; else echo "$*"; fi
eval $*
}
user=`echo $1 | awk -F@ '{print $1}'`
host=`echo $1 | awk -F@ '{print $NF}'`
if [ "$user" = "$host" ]
then
LOGNAME=${LOGNAME:=`id | sed -e 's/^[^\!(]*(//' -e 's/).*//'`}
user="-l $LOGNAME"
else
user="-l $user"
fi
RSH="$RSH_CLIENT $host $user"
RP=/usr/bin/X11:/usr/openwin/bin:/usr/X11R6/bin
if [ "`echo $DISPLAY | awk -F: '{printf $1}'`" = "" ]
then
DISPLAY=`hostname`:0
fi
execho xauth extract - $DISPLAY \| $RSH env PATH=$RP xauth -f .Xauthority
merge -
**********
The email I sent to the list was:
> Hello,
>
> I hope the questions below are not too trivial, but unfortunately I'm
> rather unfamiliar with the security and access methods to establish a
> CDE/Motif X-windows session to another computer. So far I've been using
> "Exodus" and MacX, which use XDMCP and are rather easy to use, but I have
> never done it from another Tru64 box. I noticed some issues which are
> unclear to me and was hopping someone could please enlighten my questions
> below:
>
> (1) I noticed that X-windows access control is managed by the programs
> "xhost" and "dxhosts". "xhost +" can be used to disable access control list
> at all, which would allow anyone to get a windows login screen if I
> understand correctly - maybe not a good idea.
>
> One thing I wonder about is that when typing xhost +host.domain.name
> followed by just "xhost" it lists allowed hosts, but it does not show them
> anymore after a system restart, where xhost just displays that access
> control is enabled or not. Subsequent logins work though. There is also
> "dxhosts", which does not seem to have this kind of problem as it lists all
> known hosts. What is the deal here please?
>
> (2) I thought it would be possible to use telnet, ssh, rsh and rlogin to
> establish a session on a remote system and run a program remotely, e.g.
> xterm. For this to work the remote session needs to know what the DISPLAY ip
> address is. I noticed so far that at least telnet and rlogin do not set the
> DISPLAY variable. Is there something I can do to automate this in e.g.
> /etc/profile using a dynamic source IP address? Why is this not done by
> default, and what does export $DISPLAY do?
>
> (3) How would I establish a CDE login session on a remote computer using
> another Tru64 server. Am I supposed to telnet to the remote computer and use
> e.g. dtlogin, or how?
>
> (4) Are there some known access configurations that should be avoided, such
> as MIT-COCKIE, etc. Could someone please make recomendations and explain how
> to manage it?
>
> (5) It seems like X-windows access control can be host or user based. Could
> someone please explain the difference in terms of how the system recognizes
> these type of logins. When is it using host, and when user based access
> control?
>
> (6) I can login to one of our servers using XDMCP from my workstation using
> XDarwin (MacOSX) or Exodus. I get the CDE login screen and can login as root
> since I added my workstation IP to /etc/securettys. However, "xhost" or
> "dxhost" don't show my workstation in its access control lists. I guess it
> sort of established some other method, e.g. MIT-COCKIE. How do I know?
>
> (6) I added a Tru64 workstation to the xhost list on a server. When I type
> "xhost" it shows it. I telnet to the server and su root. The workstation is
> also in /etc/securettys. I type DISPLAY=merlin.rferl.org:0, followed by
> export DISPLAY. Typing "set" shows it. But when I try to run xterm it gives
> an error: xlib: connection to "merlin.rferl.org:0" refused by server, Xlib:
> Client is not authorized to connect to Server, Error: Can't open display:
> merlin.rferl.org:0. What is wrong please?
>
> Thanks a lot for any response!
>
>
> Best regards,
>
> RFE/RL, Inc.
> Markus Waldorf
