enable remote X-client connections to Xorg server

Latest response

Hello Folks,

can someone tell me how to configure the Xorg server on RHEL 6.4 to allow incoming remote X11 connections?

(I know this is a security consideration. I also know how to tunnel X11 connections via ssh. Please don't offer alternative solutions.)

thanks,
Rob

Responses

It doesn't HAVE to be a security concern. Once you've configured XDM, you can use Xnest over an SSH pipe to get your full remote desktop (which, I'm assuming what you mean by "allow incoming remote X11 connections since doing per-client X-redirect is fairly trivial). There's several good tutorials on the subject of enabling full desktop functionality. I think I used this one, last year, when a customer was asking for similar capability on their remote/headless RHEL 6 systems.

Thanks, but this is exactly what I was trying to avoid.
I need to be able to "export DISPLAY=rhel64system:0" on an ancient Solaris box and have the X server on rhel64system allow incoming connections. I don't give a damn about the security aspects. The network is secure. There is no ssh on the Solaris box.
I'm looking for the Xserver setting to get the Xserver to listen on 0.0.0.0:6000. That's all.
cheers,
Rob

There really arent X-server settings to modify, thus my confusion about your initial post. There's really only two likely things that would keep you from doing what you're wanting: iptables and standard X session protection. To overcome these:

  • shut off iptables
  • type xhost + on one of your console session's xterms.

If you want to persist this capability across reboots, then

  • do a chkconfig iptables off
  • update your .xinitrc or similar file in your Red Hat login-user's account.

For some time Fedora has disabled incoming remote connections using the "-nolisten" flag on the Xserver. I see this on my F21 system too. It's a real PITA to turn it off (i.e., enable incoming connections).
I assumed that RHEL6.4 is the same. The system in question is at a customer, so I can't check, but I will install a test system to check it.
Thanks for your help.
Rob

-nolisten is an XDMCP option, not an X-server option, per se. You'd generally only be looking to override that on a remote system if you were looking to use an XDM browser to connect to the remote system.

When you say something like:

I need to be able to "export DISPLAY=rhel64system:0"

That implies that you're using telnet/rsh/ssh/etc. to establish a connection to the remote host and that you want to redirect a remote X-client (e.g., an xterm, a Java UI or the like) back to your local X-server.

Saying:

I'm looking for the Xserver setting to get the Xserver to listen on 0.0.0.0:6000

Makes it sound like you're looking to make your graphical desktop remotely-manageable. That's typically the job of XDMCP. Technically, the X-server is already listening just as you're requesting, but XDMCP isn't. Thus the first link I posted.

The thing you need to clarify is "what are you looking to do". Are you looking to do just X-redirection or are you looking for remote XDMCP-based management? If the latter, are you looking to display the ancient Sun host's desktop on your Red Hat box's display hardware or vice versa (if vice-versa, the link I shared applies)? If the former, it doesn't require changes to rhel64system host's XDMCP security: all you need to do is configure your firewall (iptables) and your session-security (xhost +) to allow it.

hmm, I thought this was a simple question.

-nolisten is an XDMCP option, not an X-server option, per se

From Xorg(1):
TCPIP
Xorg listens on port 6000+n, where n is the display number. This
connection type can be disabled with the -nolisten option (see the
Xserver(1) man page for details).

I'm trying to discover the magic RHEL6.4 config option to avoid having Xorg started with the "-nolisten" option.

My scenario:
- I telnet into solarisbox (it doens't matter from where).
- I set my display variable to the RHEL6.4 system:
$ export DISPLAY=rhel64system:0
- I start some random X client
$ xterm
- the xterm window opens on display0,screen=0 of rhel64system.

I just want to be able to use the "good old" X11 network transport, which was standard 20 years ago.

cheers,
Rob

In general, if given system has an X-server on it, it's being managed. Most typically, it's being managed by an XDMCP conformant service such as XDM or GDM. It's those managers that you configure the listening characterstics of. Thus, my statement that it's "not an X-server option, per se".

If, on the other hand, you've just got a bare X-server running (i.e. just they grey, stippled background with no login users associated with it), then you could probably do direct configuration of the X-server to act as an "all comers" display device. To be honest, in 25+ years of managing Unix systems, I've not encountered anyone running such an unmanaged X-server (and, by extension, I've never knowingly seen a Red Hat system configured to run that way).

All I've ever dealt with were managed displays - either via local or remote XDMCP connection. Those display-managers have all required users to login with a user account and start a session within that manager-service. Once in, it's all session-level control (with tools like xhost and Xauth to mediate further access to the session) and host or network firewalls gating what gets to the session interfaces.

One last try.

I finally got around to installing a vanilla RHEL 6.4 system ("Desktop").
I logged in as the user I'd created at the end of the installation, opened a terminal, and typed "xhost +", which responded with:
access control disabled, clients can connect from any host

next, I went to another Linux box and typed "xterm -display rhel64system:0", and got:
xterm: Xt error: Can't open display: rhel64system:0

Back on rhel64system, "ps ax| grep Xorg", which shows:
2423 tty1 Ss+ 0:08 /usr/bin/Xorg :0 -nr -verbose -audit 4 -auth /var/run/gdm/auth-for-gdm-XuaSJz/database -nolisten tcp vt1

This is exactly what I was expecting, as the Xorg config on Fedora is identical. The question remains: what config file needs to be changed in order to get the Xorg server to listen on 0.0.0.0?

Rob

I will answer my own question, because it's so much fun.

putting "DisallowTCP=false" in the "[security]" section of /etc/gdm/custom.conf will cause Xorg to listen for incoming TCP connections on 0.0.0.0.

Rob

Congratulations. After hashing back and forth, insisting that the fix wasn't in GDM, you ended up implmenting EXACTLY what was in the link I posted in my initial reply.

Bravo.

Using the DisallowTCP=false setting in custom.conf on RHEL 6.8 causes "-nolisten tcp" to be removed from the Xorg arguments as expected; however, Xorg still doesn't open a listener for port 6000, even after a reboot. So no matter what xauth or xhost settings you have, you can't get remote clients to display without tunneling X over SSH -- in other words, Xorg will only accept local connections. I tried this on an RHEL 6.3 box, and Xorg does then listen on port 6000, and xauth'ed connections work from remote clients.

Seems to me some security patch was introduced between 6.4 (Rob's world) and 6.8 to cause Xorg to not listen for remote clients, regardless of settings. Or else there's something besides custom.conf that needs to be edited.

Thoughts?

I agree with David. Modifying the custom.conf had worked up until 6.4. Recent upgrade to 6.8 has broken this functionality. We also need this to display X back from old Sun boxes to Redhat.

I ran into a similar issue on RHEL 6.8, and found that starting X with explicit "-listen tcp" arguments on the command line allowed X clients to connect over TCP.

Redhat released an updated rpm for Xorg after Redhat 6.8 that fixed it for us (until they try to remove it again) Packages were updated to xorg-x11-server-common-1.17.4-9.5.el6_8.x86_64.rpm and xorg-x11-server-Xorg-1.17.4-9.5.el6_8.x86_64.rpm.

So, being X now requires the new argument "-listen tcp" and the display manager that comes with Redhat 7 (GDM) does not support this new argument. How was Daniel Dadap able to start X with the explicit "-listen tcp" argument?

Thanks so much for this thread and the info/temp solution provided.