LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Newbie (http://www.linuxquestions.org/questions/linux-newbie-8/)
-   -   The difference in settings: console from desktop & ssh as DISPLAY not set when ssh in (http://www.linuxquestions.org/questions/linux-newbie-8/the-difference-in-settings-console-from-desktop-and-ssh-as-display-not-set-when-ssh-in-817626/)

wikapuki 07-02-2010 08:28 AM

The difference in settings: console from desktop & ssh as DISPLAY not set when ssh in
 
Hi

Debian Squeeze: Linux jilldando 2.6.32-trunk-486 #1 Sun Jan 10 05:53:18 UTC 2010 i686 GNU/Linux

gdm for desktop manager

I have 4 differences situations, 2 work, 2 do not: So I think my server box (Jill) is messed up.

1) On the server desktop, I can open a console as the gui logged in user and type:
xeyes
and those eyes appear.
echo $DISPLAY
:0.0


2) If from that console I log in as another user (ros) and then type:
xeyes
I get:
Error: Can't open display:
echo $DISPLAY
(NOTHING)
so that will be a problem.


3) If I ssh into my offices remote server from my XP machine with putty and x-forwarding and then type:
xeyes
and those eyes appear.
echo $DISPLAY
localhost:11.0


4) If I ssh into Jill from my XP machine with putty and x-forwarding and then type:
xeyes
I get:
Error: Can't open display:
echo $DISPLAY
(NOTHING)
so that will be a problem.


This leads me to think I have something messed up on my Linux box Jill.

I have tried setting DISPLAY= to various values but same error, so this led me to believe something else needs setting. Especially as env yields alot more in situation 1 than in situation 2.

What can I set where, that will allow me run xeyes (anything X) in situations 2 and 4, just like in situation 1 and 3?

AlucardZero 07-02-2010 09:05 AM

2) You have to transfer the magic cookie and also set DISPLAY to be the same. See http://www.debian-administration.org/articles/494
4) Is X11Forwarding enabled in /etc/ssh/sshd_config? If no, change it to yes, restart SSHD, and retry.

zordrak 07-02-2010 09:11 AM

in case 2:

To run something as root:

$ su -
# xauth merge ~<gui-logged-in-user>/.Xauthority
# export DISPLAY=localhost:0.0
# xeyes


To run something as another user, there are a number of options, some more complex than others, but the simplest is to just allow all connections from localhost:

$ xhost +localhost
$ su - ros
$ xeyes



in case 4:

You probably don't have X11Forwarding enabled in the sshd_config on Jill.. enable it and restart sshd.

zordrak 07-02-2010 09:12 AM

Hm. Perhaps I should reload before replying :) Ah well..

MensaWater 07-02-2010 09:13 AM

For the PuTTY X tunnel the issue is that when you login as a user you are establishing a fake display that tunnels back through your ssh connection. Also when you do that kind of tunnel it creates a file in your original user's home directory called .Xauthority (and may set a $XAUTHORITY variable).
You can do an su and use the same tunnel but it requires that you:
1) Set permissions on original user's .Xauthority so that new user can read it.
2) echo $DISPLAY (original user)
3) Switch user (su - <newuser>)
4) export DISPLAY=<DISPLAY of Original user>
5) export XAUTHORITY=<path to .Xauthority of original user>
That is to say AFTER switching user you must set both the DISPLAY and XAUTHORITY variables so they are using what the original user did.

Note that setting permissions on .Xauthority for others to read means anyone that can read it can use the tunnel to your XP system so you should do this sparingly and undo it when done.

For the console issue I don't see the same problem on my CentOS 5 console. However I do notice that unlike the PuTTY session my console session has XAUTHORITY variable set and it is a file in /tmp. It may be security on your distro is such that you have to set DISPLAY and XAUTHORITY after su similar to the way you do it for PuTTY. Just echo your $XAUTHORITY in step 1 to see what it is using then use that path in step 5.

MensaWater 07-02-2010 09:16 AM

Quote:

Originally Posted by zordrak (Post 4021744)
Hm. Perhaps I should reload before replying :) Ah well..

Perhaps instead of giving a user the equivalent of RTFM you might actually try to answer the question. :tisk:

zordrak 07-02-2010 09:18 AM

Quote:

Originally Posted by MensaWater (Post 4021750)
Perhaps instead of giving a user the equivalent of RTFM you might actually try to answer the question. :tisk:

Explain. I don't see why you think my reply was an RTFM.

MensaWater 07-02-2010 09:25 AM

Because all you did was provide a series of links. The first one goes to a page talking about NFS. If the answer is somewhere within one of the links then maybe you could point out WHICH one it is in and give some indication as to WHERE in the page yo think the answer is. Otherwise all you've done is provided a list of reading material which may or may NOT (and I'm guessing NOT) be germane to the question asked.

zordrak 07-02-2010 09:30 AM

Quote:

Originally Posted by MensaWater (Post 4021765)
Because all you did was provide a series of links. The first one goes to a page talking about NFS. If the answer is somewhere within one of the links then maybe you could point out WHICH one it is in and give some indication as to WHERE in the page yo think the answer is. Otherwise all you've done is provided a list of reading material which may or may NOT (and I'm guessing NOT) be germane to the question asked.

1. Dismount high-horse.
2. Re-read.

Once those steps are complete you will notice that the links are within my signature and that the post regarding "maybe i should reload.." is a *second* reply; the first being the one with the answer to the OP's queries.

MensaWater 07-02-2010 09:40 AM

My apologies.

I'd swear your first reply wasn't there when I responded to you the first time - I note both your replies and mine show being exactly 1 minute apart so maybe it somehow delayed post of your first reply when I saw it after clicking on my reply to OP. There was no reply at all before I started replying to OP.

wikapuki 07-02-2010 09:44 AM

This was the solution with the addition of also set DISPLAY for situation 2

Cant believe I did not think to check 4!! ;-(

Quote:

Originally Posted by AlucardZero (Post 4021737)
2) You have to transfer the magic cookie and also set DISPLAY to be the same. See http://www.debian-administration.org/articles/494
4) Is X11Forwarding enabled in /etc/ssh/sshd_config? If no, change it to yes, restart SSHD, and retry.



All times are GMT -5. The time now is 04:51 AM.