On Jun 12, 2012, at 1:43 PM, Camaleón wrote:
On Tue, 12 Jun 2012 01:03:24 -0700, Rick Thomas wrote:
On Jun 9, 2012, at 3:31 AM, Camaleón wrote:
Given that you are login on your own computers you can try with "-Y"
flag
(untrusted X11 forwarding) and see how it goes.
Another test you can run is by creating a new user and launching
"slogin -X -vvv macs xterm" session from there.
Thanks for the help...
Neither the -Y option, nor trying a brand-new user made any
difference.
And with both options, are you still getting the same log entries?
Any more suggestions? I'm still puzzled by this one!
Yup, it's not normal that it works from some clients but not for
others.
Lets see, server's the same, is client what changes... mmm, you can
compare the client openssh versions and look for any difference here
and
you can also try to run sshd (the server part) with debug mode
turned on,
there can be also something of interest here...
Besides... once you login, can you manually set the display
environment
variable fine and run xterm or it also fails?
I think I haven't been clear.
First, some definitions:
"client" = the machine I type "slogin -X server" on.
"sever" = the machine running sshd to which the above "slogin"
connects.
Server is running Debian Squeeze powerpc (there are actually two such
machines, but the results are the same for both). Client is (actually
a number of machines) running MacOS-X Leopard, MacOS-X Snow-Leopard,
Debian Squeeze-i386 and Deebian Squeeze armel.
Prior to running the recent full-upgrade on the servers, I was able to
do "slogin -X" from any and all of the clients and get an X session
with a defined "DISPLAY" variable in the env (on the servers). I
could, for example, start up an xterm on the servers from such a
session.
After running full-upgrade on the servers (they had been out of action
for a couple of months, so it was a fairly large upgrade -- which
makes diagnosing the problem harder...) when I did "slogin -X" from
any of the clients, the resulting session had no "DISPLAY" variable in
its env. Moreover, defining "DISPLAY=localhost:10.0 ; export DISPLAY"
did not help. I get "xterm Xt error: Can't open display: localhost:
10.0" error-message.
I tried creating a new account on one of the servers, with a bare-
bones home directory (nothing X related in it) and doing "slogin -X
newuser@server" didn't change anything. Same with "slogin -Y server".
The exact output of "slogin -vvv -X server" varies from one client to
another, but they all mac clients have some variation on
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-6LuZsOhrh3/
xauthfile generate /tmp/launch-Gk6NLm/:0 MIT-MAGIC-COOKIE-1
untrusted timeout 1200 2>/dev/null
debug2: x11_get_proto: /usr/X11R6/bin/xauth -f /tmp/ssh-6LuZsOhrh3/
xauthfile list /tmp/launch-Gk6NLm/:0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
and all Debian clients have some variation on:
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessi...@openssh.com
debug1: Entering interactive session.
debug2: callback start
debug2: x11_get_proto: /usr/bin/xauth list unix:10.0 2>/dev/null
debug1: Requesting X11 forwarding with authentication spoofing.
debug2: channel 0: request x11-req confirm 0
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.
debug3: Ignored env TERM
debug3: Ignored env SHELL
debug3: Ignored env XDG_SESSION_COOKIE
debug3: Ignored env SSH_CLIENT
debug3: Ignored env SSH_TTY
debug3: Ignored env USER
debug3: Ignored env LS_COLORS
debug3: Ignored env MAIL
debug3: Ignored env PATH
debug3: Ignored env PWD
debug1: Sending env LANG = C
debug2: channel 0: request env confirm 0
debug3: Ignored env SHLVL
debug3: Ignored env HOME
debug3: Ignored env LOGNAME
debug3: Ignored env SSH_CONNECTION
debug3: Ignored env DISPLAY
debug3: Ignored env _
debug2: channel 0: request shell confirm 1
debug2: fd 3 setting TCP_NODELAY
debug2: callback done
debug2: channel 0: open confirm rwindow 0 rmax 32768
debug2: channel_input_status_confirm: type 99 id 0
debug2: PTY allocation request accepted on channel 0
debug2: channel 0: rcvd adjust 2097152
debug2: channel_input_status_confirm: type 99 id 0
debug2: shell request accepted on channel 0
Again, whether it's a Mac client or a Debian client makes no
difference to the result. I do not get a "DISPLAY" in the env of the
resulting session.
I'll try running sshd on the server with debug output turned on.
There may be something there that we're not seeing in the client's
debug log.
And thanks again, for your interest in helping me debug this.
Rick
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/67abccc8-0b28-49ae-b482-761693302...@pobox.com
