I stand corrected. Regards, Lec On 06/26/2015 07:22 PM, Stuart Barkley wrote: > On Fri, 26 Jun 2015 at 03:16 -0000, 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