>>>>> "WM" == Wolfgang Meiners writes:

WM> I have a laptop (pbook) and a desktop (ubuntu) and sometimes i
WM> need (want) to do administrative work from pbook at ubuntu. I can
WM> connect via ssh and that works well. Nevertheless, i can only
WM> connect to a nonadmin acount on ubuntu. So i su to adminloc (the
WM> local admin on ubuntu) and to run X-applications i have to share
WM> the MIT-Magic-Cookie.


WM> pbook:~ wolfgang$ ssh -CX ubuntu Last login: Sat Oct 11 12:14:32
WM> 2008 from pbook.lan wolfgang@ubuntu:~$ xauth list ubuntu/unix:0
WM> MIT-MAGIC-COOKIE-1 c2a4726d56d808390f26b09a99a5f7c7
WM> localhost.localdomain/unix:0 MIT-MAGIC-COOKIE-1
WM> c2a4726d56d808390f26b09a99a5f7c7 ubuntu/unix:10 MIT-MAGIC-COOKIE-1
WM> be7db8429dcf92831256e7a1b9ded417

WM> #So there are two users, one sitting in front of the desktop #and
WM> the laptop which ssh'ed to the desktop

WM> wolfgang@ubuntu:~$ xauth extract test $DISPLAY No matches found,
WM> authority file "test" not written wolfgang@ubuntu:~$ echo $DISPLAY
WM> localhost:10.0

WM> #this confuses me. How does X-forwarding work, when the
WM> #DISPLAY-Variable is not set correct?

WM> wolfgang@ubuntu:~$ xauth extract test ubuntu/unix:10
WM> wolfgang@ubuntu:~$ ls -al test -rw-r--r-- 1 wolfgang wolfgang 52
WM> Oct 11 12:16 test

WM> #This does work, but to know what cookie to extract, #i have to
WM> xauth -list before

WM> wolfgang@ubuntu:~$ su adminloc Password:
WM> adminloc@ubuntu:/home/wolfgang$ xauth merge /home/wolfgang/test
WM> adminloc@ubuntu:/home/wolfgang$ xauth list ubuntu/unix:10
WM> MIT-MAGIC-COOKIE-1 be7db8429dcf92831256e7a1b9ded417

WM> #so this works to, and i can do i.e.

WM> adminloc@ubuntu:/home/wolfgang$ xeyes
WM> adminloc@ubuntu:/home/wolfgang$ exit exit wolfgang@ubuntu:~$ exit

WM> What i dont understand is: Why is there a DISPLAY localhost:10.0
WM> but no corresponding MIT-Magic-Cookie and how does X-forwarding
WM> work in this case? Is there something misconfiguered in my system?

Just a guess: there are versions of Xlib that do funky, heuristic things
when matching display names to sockets, especially when the host is the
local host. In this case, the names "ubuntu" and "localhost" refer to the
same host (try "xauth -n list"; do you have "127.0.0.1 ubuntu" in
/etc/hosts?). And even though the display name in xauth specifies a Unix
domain socket, Xlib probably tries that first, then falls back to TCP when
that doesn't work (try verifies this with strace).

WM> Maybe the ssh-versions are of interest: pbook:~ wolfgang$ ssh -V
WM> OpenSSH_5.1p1, OpenSSL 0.9.7l 28 Sep 2006

WM> wolfgang@ubuntu:~$ ssh -V OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL
WM> 0.9.8g 19 Oct 2007

WM> Thank you for any information Wolfgang

--
Richard Silverman
res@qoxp.net

Richard E. Silverman schrieb:
>>>>>> "WM" == Wolfgang Meiners writes:
>
> WM> wolfgang@ubuntu:~$ xauth extract test $DISPLAY No matches found,
> WM> authority file "test" not written wolfgang@ubuntu:~$ echo $DISPLAY
> WM> localhost:10.0
>
> WM> #this confuses me. How does X-forwarding work, when the
> WM> #DISPLAY-Variable is not set correct?
>
> WM> What i dont understand is: Why is there a DISPLAY localhost:10.0
> WM> but no corresponding MIT-Magic-Cookie and how does X-forwarding
> WM> work in this case? Is there something misconfiguered in my system?
>
> Just a guess: there are versions of Xlib that do funky, heuristic things
> when matching display names to sockets, especially when the host is the
> local host. In this case, the names "ubuntu" and "localhost" refer to the
> same host (try "xauth -n list"; do you have "127.0.0.1 ubuntu" in
> /etc/hosts?).

There is (was) a line
127.0.0.1 ubuntu ubuntu.lan
in /etc/hosts, i commented this line out. But this did not change
anything. "xauth -n list" shows the same as "xauth list", it is the line

ubuntu/unix:10 MIT-MAGIC-COOKIE-1 ....

> And even though the display name in xauth specifies a Unix
> domain socket, Xlib probably tries that first, then falls back to TCP when
> that doesn't work (try verifies this with strace).

I run on ubuntu strace -o /tmp/xeyes.strace xeyes

and got a very large output file. I think you are right, but i have to
study the contents of this file to find out, what it means.

So when i understand you right, it is a inconsequence (to have a
$DISPLAY localhost:10.0 without a corresponding MIT-Magic-Cookie) but i
have to live with this. Maybe pam_xauth can work around this?

Thank you for your Information
Wolfgang