-- Chander Ganesan Information Technology Arizona State University C_at_asu.edu --------------------------------------------------------------------------- From: Kevin Oberman <oberman_at_es.net> To: Chander Ganesan <C_at_asu.edu> Subject: Re: X authority/ xauth not working... solaris compatibility? [QUOTED TEXT DELETED] Because of U.S. export rules, this is much more complex than it should be. :-( I have found that extract and merge typically just don't work well. There are several problems, the biggest being that some systems use weak MIT-COOKIE-1 cookies while others use DES encrypted (non-exportable) XDM-AUTHORIZATION-1 cookies. DU uses either, but most systems seem to use only the MIT cookies because the exportable X11 lacks the DES code to allow XDM to be used. (It is readily available from many non-U.S. sites.) So I have found the best (though less secure way to do this is to use the list and add operations. On the local system (the one with the display you are looking at), enter the command: % xauth list DISPLAY where DISPLAY is the full display name, not :0.0. To get an idea of what to ask for, use xdm list to get a complete list. Then log into the remote system and enter the command: % xauth add KEY where key is the MIT or XDM cookie obtained in the previous list. If you don;t know what will work, try the XDM key first. It's must safer. If the remote system won't support it, try the MIT cookie. Here is a real example from my systems. 1. On the system I am using, kzin.lbl.gov, % xauth list kzin.lbl.gov:0 kzin.lbl.gov:0 MIT-MAGIC-COOKIE-1 23602e371e310f062e077f521976550e kzin.lbl.gov:0 XDM-AUTHORIZATION-1 6c0a1d56516318060015511252204b78 Then, I telnet into ptavv.es.net and enter the command: % xauth add kzin.lbl.gov:0 XDM-AUTHORIZATION-1 6c0a1d56516318060015511252204b78 and try running an X application like xclock. If it fails, I will try: % xauth add kzin.lbl.gov:0 MIT-MAGIC-COOKIE-1 23602e371e310f062e077f521976550e and try again. One should work. A better (MUCH better) solution is to use ssh. It encrypts the data stream and automatically does the xauth stuff. It also can eliminate the passing of clear passwords over the network. See http://www.cs.umr.edu/~smull/cs285/research/links.html for lots more information on ssh. Good luck, -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman_at_es.net Phone: +1 510 486-8634 ---------------------------------------------------------------------------- Date: Wed, 14 May 1997 11:16:19 +0700 (NSD) From: "Irene A. Shilikhina" <irene_at_alpha.iae.nsk.su> To: Chander Ganesan <C_at_asu.edu> Subject: Re: X authority/ xauth not working... solaris compatibility? Hello Chander, I can't be sure, but it seems to me I had a similar problem some days ago. One of our users could not log in from Xterminal. He had messages about failure authorization though the host is inserted to the files appropriate to the C2 security system installed. Since in the PC setup the "xdmkey" was dropped, all is OK. Later, I had a look to the xdm manual and saw that in our xdm configuration file mentioned is the file /usr/var/X11/xdm/xdm-keys, but it does not exist endeed. From the manual, the file must consist of entries each to be a pair of the terminal name and the key shared with the Xterminal. As to this facility, I didn't try it. Nevertheless, I noted "Display identifier" in the PC setup which isn't coincident with the host name. If you wish to try, pay attention to it. I assume, it's the Display identifier which is to be pointed in the /usr/var/X11/xdm/xdm-keys. I dare to write about it exclusively by reason of absence of a summary as you mention. Good luck, Irene. _______________________________________________________________________________ Irene A. Shilikhina (e-mail: irene_at_alpha.iae.nsk.su) Institute of Automation & Electrometry Novosibirsk, Russia _______________________________________________________________________________ ---------------------------------------------------------------------------- Date: Wed, 14 May 1997 10:48:13 +0100 (BST) From: William Flett <will_at_dcs.rhbnc.ac.uk> To: Chander Ganesan <C_at_asu.edu> Subject: Re: X authority/ xauth not working... solaris compatibility? On Tue, 13 May 1997, Chander Ganesan wrote: > I seem to be having some problems with X authority files > granting access to Xterms on Solaris boxes (and perhaps others) . > > Has anyone gotten this to work as expected? If so how? > Chander Ganesan Dear Chander, I've included a perl script written by someone here that'll give everyone on your systems an easy way of using xauth access controls. Just install it as /usr/local/bin/xauthsend and try it out. Failing that modify the short quick bodge Bourne shell script also supplied (it relies on an .rhosts entry for password free rsh access to the target host). Good luck, -Will Flett Computer Science Department | mail: W.Flett_at_dcs.rhbnc.ac.uk Royal Holloway, University of London | talk: +44 1784 443428 (direct) Egham, Surrey TW20 0EX, England | fax: +44 1784 439786 *************** xauthsend perl script *************** #! /usr/bin/perl #============================================================================== # xauthsend # ========= # This script makes it easier to transfer X authorisation from one machine to # another, and is particularly useful in cases where .rhosts trusting is not # permitted. It should be run on the local machine; it displays the commands # you need to type on the remote machine. # The script requires xauth to be in the PATH. # Copyright: # This script was written by Bob Vickers of ULCC (R.Vickers_at_ulcc.ac.uk). You # are free to copy it (at your own risk) provided this notice is included. The # author would be pleased to receive comments and bug reports, but does not # promise to act upon them. # I have now moved to Royal Holloway University of London and further # enhanced xauthsend. My e-mail is now R.Vickers_at_dcs.rhbnc.ac.uk # $Log: xauthsend,v $ # Revision 2.0 1996/08/13 13:08:57 bobv # First Royal Holloway version. # # Revision 1.2 1996/08/13 12:58:24 bobv # This is the version copied from ULCC. # # Revision 1.2 94/10/07 17:51:15 czis303 # include copyright notice. # # Revision 1.1 94/10/07 17:46:57 czis303 # Initial revision # # #============================================================================== $DISPLAY = $ENV{'DISPLAY'}; die "\$DISPLAY not set, cannot use X clients. Stopped" unless "$DISPLAY"; # Some systems use a display of "local:0" which confuses xauth. So we # change it to ":0". $DISPLAY =~ s/^local:/:/ ; # get authorisation info (magic cookie or whatever). $_=`xauth -i list $DISPLAY` || die "No xauth information available for display $DISPLAY.\n Stopped"; # extract display name from $authline; if the display is something like ":0.0" # then xauth will expand it slightly. ($disp, $protocol, $cookie) = split; # now extract hostname (if any) from display. ($disphost, $junk) = split ('[:/]', $disp); # if hostname has no dots then run it through gethostbyname to try and turn it # into a fully-qualified name. if ( $disphost =~ /^[^.]+$/ ) { ($longhost,$junk) = gethostbyname("$disphost"); $disp =~ s/$disphost/$longhost/; } # now remove any /unix (or /anything_else) from the display name. $disp =~ s%/.*:%:% ; # Now instruct the user. print <<EOFouter To authorise a remote system to use display $DISPLAY you should cut and paste a few lines and execute them on the remote system. If your remote shell is sh, ksh, bash or zsh then execute: DISPLAY=$disp ; export DISPLAY xauth <<EOF add $disp \\ $protocol $cookie EOF If your remote shell is csh or tcsh then execute: setenv DISPLAY $disp xauth <<EOF add $disp $protocol $cookie EOF EOFouter # ----------------------EMACS stuff to assist editing ------------------------ # Local Variables: # mode:text # tab-stop-list:(4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76) # End: ********* end of perl script ********* ********* start of bourne shell script ******** #!/bin/sh rsh tartan /usr/openwin/bin/xauth remove ncd4:0 cookie=`/usr/bin/X11/xauth list | grep ncd4` rsh tartan /usr/openwin/bin/xauth add ${cookie} ********* end of bourne shell script ******** ---------------------------------------------------------------------------- Date: Wed, 14 May 1997 07:24:26 -0700 From: rnfrank_at_pierce.llnl.gov To: C_at_asu.edu Subject: Re: X authority/ xauth not working... solaris compatibility? Greetings, I am using an NCD terminal to X to DEC UNIX 4. I start a telnet session and then execute the following script (WOLFRM is the name of the Xterm). It also seems that each user must go to App MAnager/System Admin/ Daily Admin/Host Manager and put the remote host in the X access list for X to work from 1 host to another . set DISPLAY WOLFRM:0 export DISPLAY /usr/dt/bin/Xsession rich frank rnfrank_at_llnl.govReceived on Wed May 14 1997 - 17:23:07 NZST
This archive was generated by hypermail 2.4.0 : Wed Nov 08 2023 - 11:53:36 NZDT