LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices

Reply
 
LinkBack Search this Thread
Old 02-19-2007, 11:31 PM   #16
miedward
Member
 
Registered: Feb 2007
Distribution: RHEL 4, SOLARIS 10
Posts: 91

Rep: Reputation: 15

Interesting, this is yet another subtle difference between how things are handled on Solaris and Linux servers (at least the ones I work with). When I ssh into to a Solaris server, I always need the .Xauthority information from the original user or I get the MAGIC COOKIE error the original poster mentioned.

That explains why all the references to this issue were for Solaris, which I thought was unusual, but didn't look into carefully.

All my Linux servers have heads, so I don't fiddle around with them over ssh quite as often. Always good to learn where the differences are.
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 02-20-2007, 08:53 AM   #17
MensaWater
Guru
 
Registered: May 2005
Location: Atlanta Georgia USA
Distribution: Redhat (RHEL), CentOS, Fedora, Debian, FreeBSD, HP-UX, Solaris, SCO
Posts: 5,773
Blog Entries: 4

Rep: Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697
Maybe I need to check it out on my HP-UX boxes. My verification was done on Linux.
 
Old 02-21-2007, 01:29 PM   #18
MensaWater
Guru
 
Registered: May 2005
Location: Atlanta Georgia USA
Distribution: Redhat (RHEL), CentOS, Fedora, Debian, FreeBSD, HP-UX, Solaris, SCO
Posts: 5,773
Blog Entries: 4

Rep: Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697Reputation: 697
Amazing - just a few minutes ago a DBA called about exactly this issue on an HP-UX box. However she was trying to "su - appuser" after logging in as root. (The opposite of what the original poster was doing.)

Using the information about .Xauthority I found the following worked:

Login as root
echo $DISPLAY
cp -p .Xauthority ~appuser ;chown appuser ~appuser/.Xauthority
su – appuser
export DISPLAY=<value from the echo above>
xterm

The xterm opened on the tunel I'd opened as root.

Of course I did NOT tell the user this because I'd have to get her to remember to clean up .Xauthority for appuser when done to insure no hole was left there. I told the user to ssh in as appuser so that the tunnel created was for appuser rather than for root.

I didn't try vice-versa (appuser su - to root) to see if it required this as well.

Last edited by MensaWater; 02-21-2007 at 01:42 PM.
 
Old 09-17-2009, 02:15 PM   #19
donax
LQ Newbie
 
Registered: Jun 2008
Location: Vejby, Denmark.
Posts: 2
Blog Entries: 2

Rep: Reputation: 0
Quote:
Originally Posted by miedward View Post

When you open an X forwarding connection (or any X connection) information about that session is put in $HOME/.Xauthority which should only be readable by that user and root. Really, you should check and make sure (more about this again later), because if anyone else can read this file, they can hijack your X connection and do all sorts of exciting things like keystroke logging et cetera because all X11 information is sent unencrypted.

So, what you can do (besides just using "su" which preserves the prior users environment, so avoids the problem) is something like the following...

#echo $DISPLAY
localhost:10.0
#su -
#cp /home/username/.Xauthority .
#chmod 600 .Xauthority
#DISPLAY=localhost:10.0
#export DISPLAY
#xterm

This should give you your xterminal on the original client display. There are lots of ways to do this, some probably more secure (and certainly many more elegant) than this, but as long as you REMEMBER TO CHMOD THE COPIED .Xauthority FILE this should be as secure as anything else, I think. Probably should delete it after you are done, just for fun.
This works fine for me. Sudo is necessary when you have access to sudo but do not have the root password.

I think more people might be running as root and then it is not a good idea to "cp /home/username/.Xauthority /root/"

Either do "cat /home/username/.Xauthority >> /root/.Xauthority"
or more correctly do:

su - donax -c " xauth list " > X11auth
xauth add $(<X11auth)

You may avoid this by changing /etc/sudoers so that it does not
change the home directory, or you can manually set
set -a
HOME=/home/username/


And by the way the xhost command is there to test if the DISPLAY
variable and authorization cookies work. Xterm is good, for sure,
but is not always present on e.g. Debian installations, like
xhost is not always available. In order to install basic X11
clients (programs) on Debian, use

aptitude install xbase-clients

:-)
 
Old 12-20-2011, 09:55 AM   #20
frisket
LQ Newbie
 
Registered: Sep 2003
Location: Ireland
Distribution: RH9
Posts: 8

Rep: Reputation: 2
Solution

What I do is this:

In your login directory on the target machine, add this to your .bashrc:
Code:
LIVE=`echo $DISPLAY | awk -F: '{print $2}' | awk -F. '{print $1}'`
xauth list | grep unix:$LIVE | awk '{print "xauth add " $0}' >xuser
That will create a file called xuser each time you log in, containing the xauth string. Now su and add this to /root/.bashrc:
Code:
XUSER=`who -m | awk '{print $1}'`
XUSERHOME=`grep ^$XUSER: /etc/passwd | awk -F: '{print $6}'`
if [ -s "$XUSERHOME/xuser" ]; then
. $XUSERHOME/xuser
echo Added xauth tokens for display for $XUSER
else
echo Original user $XUSER left no indication of X job
fi
That will pick up the authentication needed from the username you logged in as, and let you run X applications as root after logging in with your own username from another machine. It's probably horribly insecure, but as the designers of ssh, su, and X didn't think to provide for this very common requirement, it's the only workable solution I know.
 
2 members found this post helpful.
Old 03-03-2012, 11:43 AM   #21
sagron
LQ Newbie
 
Registered: Mar 2012
Posts: 1

Rep: Reputation: Disabled
I prefer this method (for sudo):

In ROOTS .bashrc add:
XAUTHORITY=/home/$USER/.Xauthority

(If no root access to homedirs (nfs mounts, etc.) chmod 777 .Xauthority file in users homedir - and change back when done.
Redhat 6.1 auto-chmods the file back to protected on next login.
 
Old 03-03-2012, 12:34 PM   #22
acid_kewpie
Moderator
 
Registered: Jun 2001
Location: UK
Distribution: Gentoo, RHEL, Fedora, Centos
Posts: 43,345

Rep: Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945Reputation: 1945
Useful info but this is a VERY OLD THREAD. Please think twice before replying.
 
  


Reply

Tags
forwarding, ssh, su, sudo, x11


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
sudo: broken pipe TiMiN8R Mandriva 3 09-17-2009 02:31 PM
Sudo: broken pipe codered54 Mandriva 1 10-06-2006 01:41 AM
sudo + x11 kurrupt Linux - Software 3 05-15-2006 08:43 AM
Sudo and ssh X11 fowarding Mike_the_Man Linux - General 1 05-03-2006 11:04 PM
Sudo and X11 programs 65_289 Linux - Software 1 05-17-2005 08:42 PM


All times are GMT -5. The time now is 08:44 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration