ControlPersist and multiple X11 forwarding.

[David Woodhouse]

Three patches attached.

One implements a 'ControlPersist' option, which when used with
'ControlMaster auto' or 'ControlMaster 'yes' make makes the master
background itself and stick around after its own primary session is
completed.

The second causes control clients to pass X11 display, auth proto and
auth data over the control socket so that appropriate X11 forwarding can
happen for each, instead of using $DISPLAY and $XAUTHORITY of the master
even for all the clients.

The third dispenses with the 'Already forwarding for a different
$DISPLAY' error, to make the second patch actually useful. We delay
opening the connection to the X server until after we've seen an
authentication attempt, and since each set of fake authentication data
is unique, we can use that to work out which server to connect to.

The third patch isn't quite ready yet. Is the way I did the use count on
the X11 forwarding structure the best way to do it? And why does the X11
connection stall after authentication, until after some other traffic
occurs between client and server?

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-4.2p1-controlpersist.patch
Type: text/x-patch
Size: 2148 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050904/cbb54e4c/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-4.2p1-controldisplay.patch
Type: text/x-patch
Size: 4241 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050904/cbb54e4c/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-4.2p1-multidisplay.patch
Type: text/x-patch
Size: 12412 bytes
Desc: not available
Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050904/cbb54e4c/attachment-0002.bin