| Summary: | Support multiple X11 forwarding in multiplexing | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | David Woodhouse <dwmw2> | ||||||||||
| Component: | ssh | Assignee: | Assigned to nobody <unassigned-bugs> | ||||||||||
| Status: | CLOSED WONTFIX | ||||||||||||
| Severity: | enhancement | CC: | djm | ||||||||||
| Priority: | P2 | ||||||||||||
| Version: | -current | ||||||||||||
| Hardware: | All | ||||||||||||
| OS: | All | ||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 1317 [details]
pass display information through controlclient socket
If we're going to use the correct $DISPLAY it's probably a good idea to let the controlclient tell the master which one to use.
Created attachment 1856 [details]
Updated multi-display patch against 5.5p1
Created attachment 1857 [details]
Updated muxclient display patch against 5.5p1
Sorry, but X11 forwarding is enough of a niche feature these days that we don't want to support protocol workarounds to support additional corner cases atop it. closing resolved bugs as of 8.6p1 release |
Created attachment 1316 [details] Handle multiple $DISPLAYs When using the ControlClient feature, X programs get forwarded to the $DISPLAY of the _master_, not the client. The X forwarding support in the SSH protocol doesn't allow for specifying a display for forwarded connections, but we can achieve it by generating different 'fake authentication data' for each one, then using that to infer which display should be used. (We have a similar bug with agent forwarding, and no 'easy' fix for that one without a protocol change. It has been suggested that because we can't fix _that_ bug, we shouldn't fix _this_ bug either, for 'consistency'. That logic seems a little flawed to me. Besides, I've tripped over the 'wrong display' thing _many_ times and I have not _once_ been bothered by the fact that I'm using the 'wrong' agent.)