Reco,I tried Xephr as you suggested. It seems to get around the -nolisten tcp choice. Since I will have to specify the display for the remote X client, I won't have to map the port, but can just use myhost:1.0 for DISPLAY. I got xclock -display myhost:1.0 working from myhost. Thanks for pointing out this option. I am still stuck, however, on the remote X traffic not getting through to my box.
I'm seeing in kern.log logging of access to port 6000, etc. as I am testing from a remote host. It is not rejecting it as far as I can tell. I used to know something about ipchains, but I will have to brush up to understand what I see from iptables -L to determine if traffic is being deflected. At first glance, it looked clean, however.
You asked to which version of CentOS I was referring: it is 6.5, the latest version. Honestly, having been involved in computing since the first days of X-Window, I can't think of another case where I observed the X server locked down. It was always left to the user to control with xhost and the default for that was closed. This behavior with Debian is totally new to me. Even my former use of earlier versions of Ubuntu I knew did not have things locked down.
I have not considered lightdm previously, so I'll have to look into it. Kevin Buchs Research Computer Services Phone: 507-538-5459 Mayo Clinic 200 1st. St SW Rochester, MN 55905 http://mayoclinic.org http://facebook.com/MayoClinic http://youtube.com/MayoClinic http://twitter.com/MayoClinic On 08/22/2014 11:14 AM, Reco wrote:
Try it this way: 1) Run (should listen tcp:6001) Xephyr :1 2) Set up port redirection: iptables -t nat -A PREROUTING -p tcp --dport 6001 \ -j REDIRECT --to-ports 6000I did find several of the executables in /usr/lib/gdm3/ have strings of "-nolisten" and "tcp" as well as other tell-tale evidence that suggest the parameter may be hard-coded. I might have to dig into the source next.Have you considered replacing gdm3 with something with more configuration options? Like lightdm, for example. Reco