On Mon, Jun 18, 2001 at 11:21:36AM -0400, Perry Metzger wrote:
> 
> Luke Mewburn <lukem@netbsd.org> writes:
> > Module Name:	basesrc
> > Committed By:	lukem
> > Date:		Mon Jun 18 10:26:33 UTC 2001
> > 
> > Modified Files:
> > 	basesrc/crypto/dist/ssh: session.c sshd.8
> > 
> > Log Message:
> > If UseLogin is enabled, disable X11Forwarding (since xauth passing doesn't
> > work in this case, so X11Forwarding is effectively useless). Document this.
> > Resolves my pr [security/13172].
> 
> This *should* work. In fact, UseLogin *should* be the way we generally
> run a program like ssh -- we use login as the interface on telnet and
> rlogin to prevent duplication of code (and bugs). Documenting it as
> broken doesn't strike me as being reasonable -- we should fix it
> instead.
> 
> Can we reopen the issue?

No, I don't think so.

Have a look at the way that X11Forwarding is implemented. It effectively
comprises of:
	* creating a tunnel for the X traffic (ssh & sshd)
	* creating a one-time $DISPLAY (e.g, "server:55") and and
	  appropriate xauth cookie for that session (ssh)
	* passing this new $DISPLAY and cookie (ssh to remote sshd to deal with)

Our login(1) can't handle the cookie (or the DISPLAY, unless it's in the
environment before-hand). Hacking login(1) to support this cookie
munging is something that I strongly object to.

Any other work-around that could be done in sshd, such as passing the real
$DISPLAY (e.g, "client:0") instead of the fake $DISPLAY (e.g, "server:55")
defeats the purpose of using ssh for this traffic to ensure integrity and
confidentiality of the X11 traffic, as well as protecting your X server
from cookie abuse from the remote site after you disconnect.

BTW: The `original' ssh 1.2.x client has the same problem WRT UseLogin.