Re: [CentOS] ssh -X versus -Y
On 07/06/2015 04:31 AM, John Hodrien wrote: EL6: ssh -X -o ForwardX11Trusted=no somehost xterm X Error of failed request: BadAccess (attempt to access private resource denied) Interesting. On Fedora 22, "-o ForwardX11Trusted=no" seems to have no effect. Copy and paste work normally with gnome-terminal, so I'm certain that X SECURITY isn't available and doesn't affect the application. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ssh -X versus -Y
On Mon, 6 Jul 2015, Liam O'Toole wrote: On 2015-07-05, Gordon Messmer > wrote: On 07/05/2015 04:51 AM, Liam O'Toole wrote: At this point, I don't think it's even possible to set ForwardX11Trusted=no any more. The X SECURITY extension was replaced with "X Access Control Extension" several years ago. The perceived difference was a general impression on my part, and not measured scientifically. Moreover, it was formed years ago, and on a variety of Linux systems. I concede that it may well be obsolete. EL6: ssh -X -o ForwardX11Trusted=no somehost xterm X Error of failed request: BadAccess (attempt to access private resource denied) ssh -Y -o ForwardX11Trusted=no somehost xterm All well. ssh -X -o ForwardX11Trusted=yes somehost xterm All well (unsurprising really, seeing as it means the same thing). -X/-Y/ForwardX11Trusted still do exactly what they've always done, no? You're trusting the remote host to not misbehave if you use -Y or ForwardX11Trusted=yes since at the very least you're opening up a fairly large information leakage to the remote host. That's fine if you do trust it, but it really isn't if you don't, surely? jh ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ssh -X versus -Y
On 2015-07-05, Gordon Messmer wrote: > On 07/05/2015 04:51 AM, Liam O'Toole wrote: >> One practical difference I have seen is the improved performance of >> -Y over -X. I have long attributed that to the relaxation of security >> controls in the former case. > > When and how did you measure that? > > The -Y change was introduced in Fedora Core 3, in November 2004. The > default was changed to ForwardX11Trusted=yes just a month or two > later. I'm not sure -X and -Y ever behaved differently on Enterprise > Linux or CentOS. > > At this point, I don't think it's even possible to set > ForwardX11Trusted=no any more. The X SECURITY extension was replaced > with "X Access Control Extension" several years ago. The perceived difference was a general impression on my part, and not measured scientifically. Moreover, it was formed years ago, and on a variety of Linux systems. I concede that it may well be obsolete. -- Liam ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ssh -X versus -Y
On 07/05/2015 04:51 AM, Liam O'Toole wrote: One practical difference I have seen is the improved performance of -Y over -X. I have long attributed that to the relaxation of security controls in the former case. When and how did you measure that? The -Y change was introduced in Fedora Core 3, in November 2004. The default was changed to ForwardX11Trusted=yes just a month or two later. I'm not sure -X and -Y ever behaved differently on Enterprise Linux or CentOS. At this point, I don't think it's even possible to set ForwardX11Trusted=no any more. The X SECURITY extension was replaced with "X Access Control Extension" several years ago. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ssh -X versus -Y
On 2015-06-26, Stuart Barkley wrote: [...] > The documentation of the practical differences between -X and -Y is > pretty obscure (mostly defering to the X Security extension > documentation). I would like to see better clarification of the > differences. One practical difference I have seen is the improved performance of -Y over -X. I have long attributed that to the relaxation of security controls in the former case. -- Liam ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] ssh -X versus -Y
I stand corrected. Regards, Lec On 06/26/2015 07:22 PM, Stuart Barkley wrote: On Fri, 26 Jun 2015 at 03:16 -, Alexandru Chiscan wrote: On 06/25/2015 11:51 PM, Stuart Barkley wrote: Then from your desktop (assuming Linux already running X) in a local xterm do something like: ssh -Y remote-system Do not use that because any user logged on the server can connect to your X server display and snoop what you are doing, open windows etc. -Y disables all the X server authentication mechanisms (http://www.x.org/wiki/Development/Documentation/Security/) I believe this is incorrect. The authentication protocols are still used (thus the need for the xorg-x11-xauth package on CentOS). This is not the same as 'xhost +' which should never be used. Both -X and -Y require read access to the ~/.Xauthority file on the remote system in order to connect back to the X server. You can see this by using the 'xauth remove' command to remove the authentication token for the display and clients can no longer connect. Note about -X versus -Y with ssh: -X enables basic X forwarding, It disables some X functionality making it "safer" to allow. -X also stops working after about 20 minutes (this is by design but not well documented). I only recently learned why it would stop working after pulling out the last of my hair. I have been using ssh X forwarding for current work use (local betwork) for more than 15 years and never got into this kind of problem from RH 7 to Centos 7, AIX and Solaris. Likewise, I've used ssh/X for 20+ years on a variety of systems. In most cases -X is sufficient, but some applications seem to require -Y and I have not dug into all of the reasons. Maybe it is some other issue that is closing your ssh connection (maybe you should use the KeepAlive options on the ssh server/client); just guessing. On Debian and FreeBSD 'man ssh_config' now shows: ForwardX11Timeout Specify a timeout for untrusted X11 forwarding using the format described in the TIME FORMATS section of sshd_config(5). X11 connections received by ssh(1) after this time will be refused. The default is to disable untrusted X11 forwarding after twenty minutes has elapsed. This option seems to have appeared in OpenSSH 6.0 [See more at the end of this email]. -Y allows the full X protocol which might be a security risk. Some applications will only work with -Y. With this, remote X applications can grab keyboard interactions, grab passwords, put windows on top of other windows (obscuring security messages), etc. For my own choice I use -Y (although I only enable it occasionally to specific systems). This is a recent behaviour change on my part with limited use to system I trust. Now that I know about the timeout I can probably just live with -X and will consider moving back to -X for my occasional use, The documentation of the practical differences between -X and -Y is pretty obscure (mostly defering to the X Security extension documentation). I would like to see better clarification of the differences. ...some additional research looking at the source code and revision history... The ForwardX11Timeout change was 5 years ago in OpenSSH 6.0. CentOS 6 still has OpenSSH 5.3 without this change (or if a patch was applied the documentation was not also patched). CentOS 7 has OpenSSH 6.6 which includes this change. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/clientloop.c.diff?r1=1.220&r2=1.221 Prior to that there was an intended hard coded 20 minute timeout since at least 2005: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/clientloop.c.diff?r1=1.137&r2=1.138 Based upon the comments in the June 2010 revision it appears that the timeout was not working correctly and perhaps was falling back to trusted authentication after 20 minutes: Add X11ForwardTimeout option to specify timeout for untrusted X11 authentication cookies to avoid fallback in X11 code to fully-trusted implicit authentication using SO_PEERCRED described at: http://lists.x.org/archives/xorg-devel/2010-May/008636.html After the X11ForwardTimeout has expired the client will now refuse incoming X11 channel opens. I will need to see it this is an unpatched security issue on CentOS/RedHat 6. If so, I claim credit for observing it as a possibility. Stuart ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] ssh -X versus -Y
On Fri, 26 Jun 2015 at 03:16 -, Alexandru Chiscan wrote: > On 06/25/2015 11:51 PM, Stuart Barkley wrote: > > Then from your desktop (assuming Linux already running X) in a > > local xterm do something like: > > > > ssh -Y remote-system > > Do not use that because any user logged on the server can connect to > your X server display and snoop what you are doing, open windows > etc. > > -Y disables all the X server authentication mechanisms > (http://www.x.org/wiki/Development/Documentation/Security/) I believe this is incorrect. The authentication protocols are still used (thus the need for the xorg-x11-xauth package on CentOS). This is not the same as 'xhost +' which should never be used. Both -X and -Y require read access to the ~/.Xauthority file on the remote system in order to connect back to the X server. You can see this by using the 'xauth remove' command to remove the authentication token for the display and clients can no longer connect. > > Note about -X versus -Y with ssh: > > > > -X enables basic X forwarding, It disables some X functionality > > making it "safer" to allow. -X also stops working after about 20 > > minutes (this is by design but not well documented). I only > > recently learned why it would stop working after pulling out the > > last of my hair. > > I have been using ssh X forwarding for current work use (local > betwork) for more than 15 years and never got into this kind of > problem from RH 7 to Centos 7, AIX and Solaris. Likewise, I've used ssh/X for 20+ years on a variety of systems. In most cases -X is sufficient, but some applications seem to require -Y and I have not dug into all of the reasons. > Maybe it is some other issue that is closing your ssh connection > (maybe you should use the KeepAlive options on the ssh > server/client); just guessing. On Debian and FreeBSD 'man ssh_config' now shows: ForwardX11Timeout Specify a timeout for untrusted X11 forwarding using the format described in the TIME FORMATS section of sshd_config(5). X11 connections received by ssh(1) after this time will be refused. The default is to disable untrusted X11 forwarding after twenty minutes has elapsed. This option seems to have appeared in OpenSSH 6.0 [See more at the end of this email]. > > -Y allows the full X protocol which might be a security risk. > > Some applications will only work with -Y. With this, remote X > > applications can grab keyboard interactions, grab passwords, put > > windows on top of other windows (obscuring security messages), > > etc. > > > > For my own choice I use -Y (although I only enable it occasionally > > to specific systems). This is a recent behaviour change on my part with limited use to system I trust. Now that I know about the timeout I can probably just live with -X and will consider moving back to -X for my occasional use, The documentation of the practical differences between -X and -Y is pretty obscure (mostly defering to the X Security extension documentation). I would like to see better clarification of the differences. ...some additional research looking at the source code and revision history... The ForwardX11Timeout change was 5 years ago in OpenSSH 6.0. CentOS 6 still has OpenSSH 5.3 without this change (or if a patch was applied the documentation was not also patched). CentOS 7 has OpenSSH 6.6 which includes this change. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/clientloop.c.diff?r1=1.220&r2=1.221 Prior to that there was an intended hard coded 20 minute timeout since at least 2005: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/clientloop.c.diff?r1=1.137&r2=1.138 Based upon the comments in the June 2010 revision it appears that the timeout was not working correctly and perhaps was falling back to trusted authentication after 20 minutes: Add X11ForwardTimeout option to specify timeout for untrusted X11 authentication cookies to avoid fallback in X11 code to fully-trusted implicit authentication using SO_PEERCRED described at: http://lists.x.org/archives/xorg-devel/2010-May/008636.html After the X11ForwardTimeout has expired the client will now refuse incoming X11 channel opens. I will need to see it this is an unpatched security issue on CentOS/RedHat 6. If so, I claim credit for observing it as a possibility. Stuart -- I've never been lost; I was once bewildered for three days, but never lost! -- Daniel Boone ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
