Need help with OpenSSH & X authorization

[Tommi Virtanen <tv@debian.org>]

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.
-- 
tv@{{hq.yok.utu,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.