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.
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.
On Debian and FreeBSD ‘man ssh_config’ now shows:
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
This option seems to have appeared in OpenSSH 6.0 [See more at the end of this email].
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.
Prior to that there was an intended hard coded 20 minute timeout since at least 2005:
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
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.