On 10/16/18 8:57 PM, mick crane wrote:
> On 2018-10-16 18:11, Greg Wooledge wrote:
>> On Tue, Oct 16, 2018 at 12:43:40PM -0400, Gene Heskett wrote:
>>> #1 is ssh -Y has been killed from jessie on. No excuse for doing it and
>>> bug filing is ignored.
>>
>> I don't know what you mean by this. I just performed the following
>> experiment on my stretch workstation (wooledg), in communications with
>> a stretch server (arc3) elsewhere on our network.
>>
>> 1) Already logged into wooledg, I opened a new urxvt window.
>>
>> 2) In this window, I typed: ssh -Y arc3
>>
>> 3) After authenticating to arc3 with a password, at the shell prompt, I
>> typed: xterm
>>
>> 4) After a moment, a new xterm window appeared on my display.
>>
>> 5) Inside this xterm, to confirm that the xterm was running on arc3,
>> I typed: uname -a
>>
>> Terminal sessions shown without modification:
>
> works here with Buster.
> "ssh -Y me@otherPC"
> "xclock"
>
> xclock appears
>
> mick
>
Hi all,
I believe the following problem was referred to, which somehow,
is network specific:
https://lists.debian.org/debian-user/2018/09/msg00836.html
Digging more in that issue shows that, somehow, the forwarding
expects the loopback address to be reachable in inet6. Indeed
the following command, run on SSH server side, is sufficient to
trigger the issue:
server$ sudo ip address del ::1/128 dev lo
On client side (whatever the real network interface configuration
is, IPv4 or 6, on client or server):
client$ ssh -Y server
login@server's password:
X11 forwarding request failed on channel 0
[...]
Putting back IPv6 support in the loopback does the trick:
server$ sudo ip address add ::1/128 dev lo
client$ ssh -Y server
login@server's password:
[...]
$ echo $DISPLAY
localhost:10.0
(this or the solution proposed previously, in the sshd_config file)
Perhaps, it could be commonly expected that, whatever the
situation is, being either at the capital, or in the middle of
the Kamchatka, the loopback would better be always addressable
both in IPv4 (127.0.0.1/8) and IPv6 (::1/128). (Modulo kernel
support maybe...)
Actually, the problem seems more complex than that, and lurks
for some years:
2007: https://bugzilla.mindrot.org/show_bug.cgi?id=1356
2013: https://bugzilla.mindrot.org/show_bug.cgi?id=2143
2017: https://bugzilla.redhat.com/show_bug.cgi?id=1436097
I understand that there is no fix in sight because SSH devs
fear to undo a fix for an old vulnerability. Given the
purpose of SSH, better be careful on the way patches are
brought indeed.
Kind Regards,
--
Étienne Mollier <etienne.moll...@mailoo.org>
