:: Re: [DNG] New behaviour under Devua…
Top Page
Delete this message
Reply to this message
Author: Didier Kryn
Date:  
To: dng
Subject: Re: [DNG] New behaviour under Devuan.
Le 22/09/2017 à 13:30, Arnt Karlsen a écrit :
> On Fri, 22 Sep 2017 13:03:07 +0200, Arnt wrote in message
> <20170922130307.25f57592@???>:
>
>> On Thu, 21 Sep 2017 16:44:47 -0700, Rick wrote in message
>> <20170921234447.GP11717@???>:
>>
>>> Quoting Arnt Karlsen (arnt@???):
>>>
>>>> ..my prefecence was the -X option: ssh -X root@localhost
>>>> until Debian killed it with some new policy.
>>> Was it Debian that did that? I was never sure. I just remember
>>> that 'ssh -X' suddenly no longer did X11 forwarding as it used to,
>>> but I looked up the problem and saw that 'ssh -Y' now did that. I
>>> never chased down the matter further.
>> ..hum, agreed, one of us should have.
>>
>>> (/me Web-searches:)
>>>
>>> It has something to do with 'untrusted X11', mentioned in passing
>>> here:
>>> https://unix.stackexchange.com/questions/12755/how-to-forward-x-over-ssh-to-run-graphics-applications-remotely
>>>
>>> -Y 'enables trusted X11 forwarding':
>>>
>>> https://serverfault.com/questions/273847/what-does-warning-untrusted-x11-forwarding-setup-failed-xauth-key-data-not-ge
>>>
>>>    "Untrusted" in this context means you don't trust the connection.
>>> SSH will use additional security measures to try to make X11
>>> forwarding safer. "Trusted" means you are entirely confident that no
>>> on on the remote host will get access to your Xauth data and use it
>>> to monitor your keystrokes for instance.

>>>
>>>    This terminology actually confused me for years. I thought
>>> "Trusted" connections were safer. But actually it's an option
>>> you're supposed to use in situations where the connection IS
>>> trustworthy and you want to run stuff without extra security
>>> measures getting in your way. "Untrusted" is the one that makes it
>>> (somewhat) safer to deal with an untrusted remote host.

>>>
>>>    An "Untrusted" connection attempts to limit what a black hat could
>>> do to you by engaging the X11 security extension and disabling other
>>>    extensions that you (hopefully) don't need. This is probably why
>>> RandR is disabled with -X. Do you need to be able to rotate your X
>>> display from the remote host?
>> ..not really, I would possibly "need" gradual rotations controlled
>> by an head tracker for use in FlightGear or flying fpv with one of
>> these:
> ..http://headplay.com/ ,  which should have been appended to the
> above colon.

>
> ..weird net "outage", I had dns, icmp and _nothing_ else,
> outside my isp's net.
>
>>>    It's also important to note that "untrusted" X11 forwarding turns
>>> off after a certain amount of time to keep you from accidentally
>>> leaving it on. New attempts to open windows will just fail after
>>> that. That bit me several times before I read enough docs to
>>> understand what was happening.
>> ..if you use passwd-free ssh authorisation, it's simply another
>> [arrow-up] hit and you're back in.

>>
>>> My surmise is, not a Debian change, so much as a Portable OpenSSH
>>> change.
>>>
>>> _______________________________________________
>>> Dng mailing list
>>> Dng@???
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>

     As far as I (vaguely) understand it, the allowed X transactions 
between the host and the client are restricted to a "secure" subset with 
-X, with respect to -Y. And this is why -Y should only used when both 
sides are trusted. Maybe they have discovered that that secure subset 
isn't secure enough. Anyway this has always been adjustable in 
sshd_config and ssh_config, both in general and per address range.


         Didier


     Didier