10:32 a.m.
Has anyone been able to run gnuclient through an ssh X connection?
How?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
11:33 a.m.
Michael Sperber [Mr. Preprocessor] may have said:
Has anyone been able to run gnuclient through an ssh X connection?
How?
I'm probably missing something. This works for me:
slogin -X server.example.com
Last login: Mon Feb 11 21:32:06
2002 from client.example.com
Sun Microsystems Inc. SunOS 5.8 Generic February 2000
Sun Microsystems Inc. SunOS 5.8 Generic February 2000
gnuclient
Cheers,
-Ted
11:52 a.m.
>>>> "Ted" == Ted Phelps
<phelps(a)dstc.edu.au> writes:
Ted> Michael Sperber [Mr. Preprocessor] may have said:
> Has anyone been able to run gnuclient through an ssh X
connection?
> How?
Ted> I'm probably missing something. This works for me:
> slogin -X server.example.com
Ted> Last login: Mon Feb 11
21:32:06 2002 from client.example.com
Ted> Sun Microsystems Inc. SunOS 5.8 Generic February 2000
Ted> Sun Microsystems Inc. SunOS 5.8 Generic February 2000
> gnuclient
Client-side, I get:
sams[41] ssh sams
Last login: Mon Feb 11 11:30:46 2002 from sams
FreeBSD 4.3-RELEASE (SAMS) #1: Mon May 7 13:35:27 MST 2001
sams[31] gnuclient
channel 0: istate 4 != open
channel 0: ostate 64 != open
... and server-side:
(2) (x/critical) I/O Error 32 (Broken pipe) on display connection
"sams:10.0" after after 0 requests (0 known processed)
with 0 events remaining.
Throwing to top level.
(This is OpenSSH 2, btw.)
I wonder how your gnuserv XEmacs gets at the necessary xauth
information. But even with that in place, things fail in the same
way.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
11:57 a.m.
Michael Sperber [Mr. Preprocessor] may have said:
sams[41] ssh sams
Last login: Mon Feb 11 11:30:46 2002 from sams
FreeBSD 4.3-RELEASE (SAMS) #1: Mon May 7 13:35:27 MST 2001
sams[31] gnuclient
channel 0: istate 4 != open
channel 0: ostate 64 != open
... and server-side:
(2) (x/critical) I/O Error 32 (Broken pipe) on display connection
"sams:10.0" after after 0 requests (0 known processed)
with 0 events remaining.
Throwing to top level.
That sucks. Do normal X applications work? xlogo is a good test :-)
(This is OpenSSH 2, btw.)
I'm using openssh-3.0.2p1 on both ends. I assume you don't need an
explicit "-X" in version 2?
I wonder how your gnuserv XEmacs gets at the necessary xauth
information. But even with that in place, things fail in the same
way.
I thought SSH X tunnel dealt with that:
ssh will also automatically set up Xauthority data on the server machine.
For this purpose, it will generate a random authorization cookie, store
it in Xauthority on the server, and verify that any forwarded connections
carry this cookie and replace it by the real cookie when the connection
is opened. The real authentication cookie is never sent to the server
machine (and no cookies are sent in the plain).
Cheers,
-Ted
12:07 p.m.
>>>> "Ted" == Ted Phelps
<phelps(a)dstc.edu.au> writes:
Ted> Michael Sperber [Mr. Preprocessor] may have said:
> sams[41] ssh sams
> Last login: Mon Feb 11 11:30:46 2002 from sams
> FreeBSD 4.3-RELEASE (SAMS) #1: Mon May 7 13:35:27 MST 2001
> sams[31] gnuclient
> channel 0: istate 4 != open
> channel 0: ostate 64 != open
>
> ... and server-side:
>
> (2) (x/critical) I/O Error 32 (Broken pipe) on display connection
> "sams:10.0" after after 0 requests (0 known processed)
> with 0 events remaining.
> Throwing to top level.
Ted> That sucks. Do normal X applications work? xlogo is a good test :-)
Yes. (They work fine from the ssh session, but XEmacs is
sitting outside the ssh session.) See below.
Ted> I'm using openssh-3.0.2p1 on both ends. I assume you don't need an
Ted> explicit "-X" in version 2?
No. (OT: This actually has nothing to do with version 2. There's an
appropriate clause in ssh_config for the host in question.)
> I wonder how your gnuserv XEmacs gets at the necessary xauth
> information. But even with that in place, things fail in the same
> way.
Ted> I thought SSH X tunnel dealt with that:
Ted> ssh will also automatically set up Xauthority data on the server machine.
Ted> For this purpose, it will generate a random authorization cookie, store
Ted> it in Xauthority on the server, and verify that any forwarded connections
Ted> carry this cookie
Right. But for the connection to carry the cookie, it needs access to
the cookie. In the setup out here, ssh stores it in a file referenced
by the XAUTHORITY environment variable.
sams[5] printenv XAUTHORITY
/tmp/ssh-m2s3yDrk/cookies
Which the XEmacs I'm connecting to of course doesn't have. If I do
the analogous thing in a local server-side xterm (with an ssh
connection to that server open), I get this:
sams[31] setenv DISPLAY sams:10.0
sams[32] setenv XAUTHORITY /tmp/ssh-m2s3yDrk/cookies
sams[33] xlogo # this works
sams[34] unsetenv XAUTHORITY
sams[35] xlogo
X connection to sams:10.0 broken (explicit kill or server shutdown).
What does (getenv "XAUTHORITY") say for you in the XEmacs started off
of gnuclient?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
1:10 p.m.
Michael,
I now realize that my initial test was bogus because I started xemacs
from the shell in which I ran gnuclient, and it therefore had all of
the context it needed to work properly. In a more rigorous test, I
am unable to make it work :-( Sorry for the false positive.
Michael Sperber [Mr. Preprocessor] may have said:
Right. But for the connection to carry the cookie, it needs access
to
the cookie. In the setup out here, ssh stores it in a file referenced
by the XAUTHORITY environment variable.
Version 3 apparently no longer uses the XAUTHORITY environment
variable:
server> ssh client
client> printenv XAUTHORITY
client> xlogo [works]
The only variables it appears to set (aside from DISPLAY) are
SSH_CLIENT and SSH_TTY, neither of which appears to be necessary:
client> unsetenv SSH_CLIENT
client> unsetenv SSH_TTY
client> xlogo [works]
It appears that the X authentication information is stored on the host
on which the pseudo-server is running, and I can launch clients from
any shell which connect to the pseudo-server. That said, when I try
to execute (make-frame-on-display "client:10.0"), xemacs just hangs.
Cheers,
-Ted
1:57 p.m.
Ted Phelps may have said:
It appears that the X authentication information is stored on the
host
on which the pseudo-server is running, and I can launch clients from
any shell which connect to the pseudo-server. That said, when I try
to execute (make-frame-on-display "client:10.0"), xemacs just hangs.
Oddly, this actually works for me
From client's display:
client> xemacs -nw
From server's display:
server> ssh -X client.example.com
phelps(a)client.example.com's password:
Last login: Mon Feb 11 13:04:30 2002 from server.example.com
Linux client 2.4.17 #4 Thu Jan 17 00:34:23 GMT 2002 i686 unknown
client> gnuclient
And I end up with an X frame on server.
I have no idea why this should make any difference.
Cheers,
-Ted
3:04 p.m.
>>>> "Ted" == Ted Phelps
<phelps(a)dstc.edu.au> writes:
Ted> Ted Phelps may have said:
> It appears that the X authentication information is stored on the
host
> on which the pseudo-server is running, and I can launch clients from
> any shell which connect to the pseudo-server. That said, when I try
> to execute (make-frame-on-display "client:10.0"), xemacs just hangs.
Ted> Oddly, this actually works for me
> From client's display:
client> xemacs -nw
> From server's display:
server> ssh -X
client.example.com
Ted> phelps(a)client.example.com's password:
Ted> Last login: Mon Feb 11 13:04:30 2002 from server.example.com
Ted> Linux client 2.4.17 #4 Thu Jan 17 00:34:23 GMT 2002 i686 unknown
client> gnuclient
Ted> And I end up with an X frame on server.
Ted> I have no idea why this should make any difference.
It doesn't here :-(
Thanks for working on this!
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
3:11 p.m.
Michael Sperber [Mr. Preprocessor] may have said:
Ted> I have no idea why this should make any difference.
It doesn't here :-(
Doh!
Thanks for working on this!
No worries :-)
It looks to me like you're dealing with more than one problem here,
one involving the passing of the X authentiction information, and the
other is possibly a bug in xemacs. I take a closer look at this later
today when I have some more time...
Cheers,
-Ted
3:15 p.m.
>>>> "Ted" == Ted Phelps
<phelps(a)dstc.edu.au> writes:
Ted> Michael Sperber [Mr. Preprocessor] may have said:
Ted> I have no idea why this should make any difference.
>
> It doesn't here :-(
Ted> Doh!
> Thanks for working on this!
Ted> No worries :-)
Ted> It looks to me like you're dealing with more than one problem here,
Ted> one involving the passing of the X authentiction information, and the
Ted> other is possibly a bug in xemacs. I take a closer look at this later
Ted> today when I have some more time...
I don't think I've gotten to the point yet where XEmacs could exhibit
a bug: It does exactly what I predict happens when I reason about the
way authentication works, at least with OpenSSH 2. (I don't see why
this should be different for xemacs -nw.) I had hoped that somebody
had already done the work to get this done right, but it doesn't seem
as though anybody has.
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
5:12 p.m.
Michael Sperber [Mr. Preprocessor] may have said:
I don't think I've gotten to the point yet where XEmacs
could
exhibit a bug: It does exactly what I predict happens when I reason
about the way authentication works, at least with OpenSSH 2. (I
don't see why this should be different for xemacs -nw.) I had hoped
that somebody had already done the work to get this done right, but
it doesn't seem as though anybody has.
I've looked at this a little more closely and the problem appears to
be a difference of opinion between a fairly old X server and a
cutting-edge X client library. If I reverse the direction of the
connection, then everything appears to work for me.
I suppose that upgrading to OpenSSH 3 is not a viable option?
Cheers,
-Ted
11:15 p.m.
On Mon, 11 Feb 2002, Michael Sperber yowled:
Right. But for the connection to carry the cookie, it needs access
to
the cookie. In the setup out here, ssh stores it in a file referenced
by the XAUTHORITY environment variable.
sams[5] printenv XAUTHORITY
/tmp/ssh-m2s3yDrk/cookies
... and this has changed between OpenSSH-2.x and 3.x. In 2.x, you get an
XAUTHORITY like that. In 3.x, XAUTHORITY is left unchanged from its
standard setting, which means that in the common case of a shared $HOME,
the Xauthority containing the ssh cookie is automatically accessible by
XEmacs.
Solution: upgrade to 3.0.2p1 and watch the silly ssh-{blah} directories
fade away (well, for that purpose, anyway; the ssh-agent still makes
them for its socket).
--
`The classical music makes him feel tranquil and loved so he performs
regularly. What a life for a guy. He gets to make love every day with
an artificial cow.'
2:11 p.m.
On Mon, 11 Feb 2002, sperber(a)informatik.uni-tuebingen.de wrote:
Has anyone been able to run gnuclient through an ssh X connection?
How?
It works for me.
This is how I startup Xemacs.
export DISPLAY=127.0.1.0:0
ssh -X -f usr(a)host.com xemacs-21.4.6
Getting this to work was half the battle, and required setting various
options in ssh_config (forwardX11 & protocol). Once the above works,
and xemacs displays on your local xserver. Then you have to do m-x
gnuserv-start and gnuclient should 'just' work.
-jeff
3 p.m.
>>>> "Jeff" == Jeff Mincy
<jeff(a)delphioutpost.com> writes:
Jeff> On Mon, 11 Feb 2002, sperber(a)informatik.uni-tuebingen.de wrote:
> Has anyone been able to run gnuclient through an ssh X
connection?
> How?
Jeff> It works for me.
Jeff> This is how I startup Xemacs.
Jeff> export DISPLAY=127.0.1.0:0
Jeff> ssh -X -f usr(a)host.com xemacs-21.4.6
Jeff> Getting this to work was half the battle, and required setting various
Jeff> options in ssh_config (forwardX11 & protocol). Once the above works,
Jeff> and xemacs displays on your local xserver. Then you have to do m-x
Jeff> gnuserv-start and gnuclient should 'just' work.
This doesn't change things for me at all. How does X authentication
work in this setting?
--
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla
8122
days inactive
8131
days old
13 comments
4 participants
participants (4)
-
Jeff Mincy -
Michael Sperber -
Nix -
Ted Phelps