Linux - GeneralThis 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.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
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 -.
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.
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.
Last edited by MensaWater; 02-06-2007 at 03:12 PM.
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.
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.
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...
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.