severity 59862 normal
thanks
To the Release Manager:
This is an RC bug I cannot reproduce, it seems rare
and probably relates to differences in local configuration
or something like that. I'm not very enthusiastic about
getting this fixed for potato (and Branden seems all out of
clues too); it does not seem (to me) that horrible to let
this one slip by. If you disagree, just say no.
To the submitter (developers, please read on):
This bug report contains mixed output from AIX ssh,
OpenSSH, etc. It also involves one buggy X version.
Could you please do the following:
-ensure you have upgraded to X 3.3.6-5, OpenSSH 1.2.2-1.4
-log in locally, via xdm
-show the output of:
printenv DISPLAY
printenv XAUTHORITY
xauth list
xauth list "$DISPLAY"
ltrace -s100 -S xset s on
ssh -v localhost
printenv DISPLAY
printenv XAUTHORITY
xauth list
xauth list "$DISPLAY"
ltrace -s100 -S xset s on
If you also see errors like
_X11TransSocketINETConnect: Can't connect: errno = 105
Error: Can't open display: ...:10.0
but with no ssh debug lines like
debug: Received X11 open request
debug: channel 0: new [X11 connection from ... port ...]
then it seems like the sshd is not creating a X11
sockets; in that case show output of
ltrace -s100 -S sshd -d -p 2222
# change xterm/console
ssh -v localhost -p 2222
printenv DISPLAY
xset s on
And please make sure there are no passwords in the
ltrace outputs.
I am pessimistic about finding this bug in time for the
freeze. I'm lowering the severity to normal; if someone
else can reproduce this bug, then I will upgrade it back
to release-critical.
To the developers:
Branden and I banged our heads together on this. No go.
If you can help, _PLEASE_ do. This used to be RC; I just
downgraded it.
Here's the current idea:
1) ssh grabs the first line of xauth list $DISPLAY
2) stores the proto and data
3) generates random fake data, same proto
4) sends proto+fake data to remote
5) remote sets up a remote:10 socket, /tmp/Xauth, with proto+fake data
6) any X requests coming in with proto+fake data get translated to
proto+real data
Some part of this seems to fail. If you read the bug report,
you will see that earlier it failed in stage 6, due to X -4
being buggy. But that does not explain the current weirdness,
now it does not seem to get all the way to item 5. The
"Can't connect" and no errors from ssh seems to indicate that
sshd did not create the socket at all -- this is why I requested
sshd -d and traces, to see the socket creation.
xdm started using XDM-AUTH-1 recently. It may be involved in
this, though it still creates a MIT-MAGIC-COOKIE-1, too -- and
it should accept it, too.
Please help; try to reproduce if nothing else.
--
[EMAIL PROTECTED],havoc,gaeshido}.fi,{debian,wanderer}.org,stonesoft.com}
unix, linux, debian, networks, security, | Serious error.
kernel, TCP/IP, C, perl, free software, | All shortcuts have disappeared.
mail, www, sw devel, unix admin, hacks. | Screen. Mind. Both are blank.
