Hello All,

How I can resolve it please?

you can start by writing a full post with actual information, defining what "broken" means to you, error messages etc...

The "-" tells it to invoke the user's environment (root user since you didn't specify one) rather than use your existing environment. The X forwarding sets the DISPLAY variable. If the environment files for root (/etc/profile, /etc/bashrc, $HOME/.profile, $HOME/.bashrc etc...) set DISPLAY they're overwriting the one you have.

Try logging in then typing "echo $DISPLAY". Then run your sudo su - and run the "echo $DISPLAY" again to see if you get the same answer before and after. If not try setting your DISPLAY to whatever it was on the one you had before the sudo su -.

e.g.
If before echo shows $DISPLAY is localhost:10.0 and after shows $DISPLAY is myworkstations:0.0 (or null) then type in "export DISPLAY=localhost:10.0" to see if it resolves your issue.

Thanks jlightner,

To continue your reply, I can do something like that (in root's .profile):

RMT_HOST=$(who -muR | awk '{print $NF}')
export DISPLAY=${RMT_HOST%%}:0.0

or

export DISPLAY=`who -mT | awk '{print $9}'`:0.0


BUT, in the context of SSH (that I didn't mentioned before, sorry) I'll lose env settings to secure X11 tunnel :-(

The deal is switching user's doesn't lose the tunnel. I tested it here before I wrote.

The DISPLAY you're seeing is NOT a real DISPLAY but a "fake" one created for the tunnel. That's why it needs to be preserved on switching users. That is to say where normally setting export DISPLAY=myworkstation:0.0 would work (assuming myworkstation accepts X traffic) it doesn't work in the tunnel because the tunnel is using the ssh port rather than the 6000 port range to send X traffic to your workstation. You therefore have to be sure the DISPLAY specified is the one that you had before the sudo su -.

Your who command would show the myworkstation real IP rather than the "fake" DISPLAY the ssh tunnel is using.

By the way - My response was based on the assumption you meant ssh tunneling.

EDIT: myworkstation above would be what you're calling RMT_HOST in your .profile. The point being that's NOT the right DISPLAY for an ssh X tunnel.

Hmmmm... thanks for clarifying, but I'm little bit confused Is it mean that I can continue same ssh session after sudo su- ?

Yes - I'm assuming that's what you were doing. Maybe I'm confused.

I thought you were doing "ssh -X remotehost"

Then on the remote host typing "sudo su -" to become root there.

Its not clear to me how you would do "sudo su -" on the originating rather than the remote host as the "ssh" itself would have you on the remote host.

Restated. Are you trying to become root on the originating host or the remote host?

yes, I'm doing sudo su- on the remote host

So you continue to use the tunnel you opened even after the "sudo su -" on the remote host. My point was that the "su -" itself is apt to override or remove the DISPLAY variable you had before the "sudo su -" on the remote host. So the sequence should be something like:

1) originating host: ssh -X remotehost

2) remote host: echo $DISPLAY

3) remote host: Verify the X tunnel is working by typing "xterm". This should open an xterm window on your originating host. You can close that.

4) remote host: sudo su -

5) remote host: echo $DISPLAY

6) Compare the answer from 2 and 5 and if NOT the same then type in:
export DISPLAY=<answer from 2>

7) remote host: Repeat the test from 3 to verify the X tunnel still works.

after sudo su- I got the next connection refusing error

"MIT-MAGIC-COOKIE-1 data did not match"

what's wrong?

I'm confused. Has this been an issue all along? I had thought from what you previously wrote that the "sudo su -" was working and it was the tunnel you're having a problem with. If "sudo su -" has been a problem all along then its a completely different issue.

If it just started make sure you're NOT changing anything BEFORE the sudo. Also you mentioned earlier you were adding the thing about RMT_HOST to your root .profile. You may wish to revert to original .profile.

Sorry for confusing - I've got MAGIC-COOKIE error just after I've revert to original root .profile and DISPLAY was set to localhost:11.0 Than I sudo su - and reset DISPLAY to localhost:11.0 on remote host. Than I've got this MAGIC-COOKIE error.

After the ssh to remote host and BEFORE you do the "sudo su -" does xterm work? (see step 3 in my earlier post).

Please respond to above before looking at the following.

Also please confirm - your "echo $DISPLAY" before the "sudo su -" shows:
localhost:11.0

So after the "sudo su -" your "echo $DISPLAY" shows something else (or nothing) and then you tried "export DISPLAY=localhost:11.0" and then xterm?

The reason you are getting an error about MAGIC COOKIES is because X11 uses cookie based security and the new root environment you made by using "su -" doesn't know about the cookie the original terminal made for the user you logged in as.

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.

Though I feel obliged to mention that I have been reading many places today that "security conscious administrators" should have Xforwarding turned off, because it makes your ssh connection less secure. Certainly using Xforwarding to do things as root should be avoided when possible, but unfortunately security and usability do not often go hand in hand...

A tunnel by its nature has a little risk but then again so does X itself on port 6000. At least the ssh tunnel does some encryption and requires one to hack the remote server rather than do man in the middle attacks like X.

The Xauthority information is good but not something I've need to do when doing "su -" - as I noted in my posts above just insuring the DISPLAY variable is the same after the su as before has worked fine for me.