LinuxQuestions.org
Register a domain and help support LQ
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices

Reply
 
Search this Thread
Old 07-02-2010, 08:28 AM   #1
wikapuki
Member
 
Registered: Jun 2009
Distribution: Debian
Posts: 78

Rep: Reputation: 15
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?

Last edited by wikapuki; 07-02-2010 at 08:37 AM.
 
Old 07-02-2010, 09:05 AM   #2
AlucardZero
Senior Member
 
Registered: May 2006
Location: USA
Distribution: Debian
Posts: 4,631

Rep: Reputation: 519Reputation: 519Reputation: 519Reputation: 519Reputation: 519Reputation: 519
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.
 
1 members found this post helpful.
Old 07-02-2010, 09:11 AM   #3
zordrak
Member
 
Registered: Feb 2008
Distribution: Slackware
Posts: 595

Rep: Reputation: 115Reputation: 115
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.
 
Old 07-02-2010, 09:12 AM   #4
zordrak
Member
 
Registered: Feb 2008
Distribution: Slackware
Posts: 595

Rep: Reputation: 115Reputation: 115
Hm. Perhaps I should reload before replying Ah well..
 
0 members found this post helpful.
Old 07-02-2010, 09:13 AM   #5
MensaWater
Guru
 
Registered: May 2005
Location: Atlanta Georgia USA
Distribution: Redhat (RHEL), CentOS, Fedora, Debian, FreeBSD, HP-UX, Solaris, SCO
Posts: 5,995
Blog Entries: 5

Rep: Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782
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.
 
Old 07-02-2010, 09:16 AM   #6
MensaWater
Guru
 
Registered: May 2005
Location: Atlanta Georgia USA
Distribution: Redhat (RHEL), CentOS, Fedora, Debian, FreeBSD, HP-UX, Solaris, SCO
Posts: 5,995
Blog Entries: 5

Rep: Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782
Quote:
Originally Posted by zordrak View Post
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.
 
Old 07-02-2010, 09:18 AM   #7
zordrak
Member
 
Registered: Feb 2008
Distribution: Slackware
Posts: 595

Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by MensaWater View Post
Perhaps instead of giving a user the equivalent of RTFM you might actually try to answer the question.
Explain. I don't see why you think my reply was an RTFM.
 
Old 07-02-2010, 09:25 AM   #8
MensaWater
Guru
 
Registered: May 2005
Location: Atlanta Georgia USA
Distribution: Redhat (RHEL), CentOS, Fedora, Debian, FreeBSD, HP-UX, Solaris, SCO
Posts: 5,995
Blog Entries: 5

Rep: Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782
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.
 
Old 07-02-2010, 09:30 AM   #9
zordrak
Member
 
Registered: Feb 2008
Distribution: Slackware
Posts: 595

Rep: Reputation: 115Reputation: 115
Quote:
Originally Posted by MensaWater View Post
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.
 
1 members found this post helpful.
Old 07-02-2010, 09:40 AM   #10
MensaWater
Guru
 
Registered: May 2005
Location: Atlanta Georgia USA
Distribution: Redhat (RHEL), CentOS, Fedora, Debian, FreeBSD, HP-UX, Solaris, SCO
Posts: 5,995
Blog Entries: 5

Rep: Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782Reputation: 782
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.
 
Old 07-02-2010, 09:44 AM   #11
wikapuki
Member
 
Registered: Jun 2009
Distribution: Debian
Posts: 78

Original Poster
Rep: Reputation: 15
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 View Post
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.
 
  


Reply

Tags
display, env, remote, ssh


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 Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
X11 over SSH: $DISPLAY not being set Dria Linux - Networking 4 10-25-2010 01:47 PM
[SOLVED] X11 forwarding problem over ssh. Where DISPLAY is set? kaz2100 Linux - Software 3 09-27-2009 05:32 AM
[SOLVED] ssh, Trying to call a friends Ubuntu desktop, Default settings? VipX1 Linux - General 12 08-30-2009 10:29 AM
ssh connection refused - trying to set up ssh server at home openSauce Linux - Server 10 10-18-2007 04:38 PM
[putty&ssh] Who is really good & expert in ssh https tunnelling and firewalling ? Xeratul Linux - General 12 12-03-2006 03:22 AM


All times are GMT -5. The time now is 01:18 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