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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
