Disable local X but allow remote X connections

[edwardb]

I have installed gentoo with the 2.4.20-gentoo-r8 kernel and kde 3.1.4. I am trying to set this machine so that I can make X connections to it, but the local console will be the normal text console. I have done this in the past with other versions of linux, but my memory has now failed me.

Any help would be appreciated.

[MasterX]

To have only text console you need to go to /etc/inittab and chage the following

[edwardb]

I seem to have left out an important piece of information. I am trying to do this so I can use the XDMCP protocol to connect, which means that kdm must be running. As soon as I start kdm it starts a local X session as well. From what little I remember from the last time the change(s) where made in kdmrc.

[MasterX]

You are right, this IS an important o]piece of information.
I did a guick search in google on XDMCP and I found something that you should know. It is NOT secure. They recommend ssh.
Anyway, if you want to use you can go to gdm.conf file (sorry I have only gdm installed) and there are a couple of lines that talk about XDMCP protocol. In one line it is written

[grant.mcdorman]

Enabling XDCMP alone still won't do what you want.

There are several things you need to do:

1. Enable XDMCP. MasterX has already said how to do this with Gnome; for KDE, go to /usr/kde/3.1/share/config/kdm and edit kdmrc:

   Code:

   [Xdmcp] # Whether KDM should listen to XDMCP requests. Default is true Enable=true

   For XDM, as far as I know it's always on.
   
2. Disable the local X server. I'm not sure how this is done in Gnome; for KDE edit /usr/kde/3.1/share/config/kdm/Xservers and comment out the display 0 line. XDM uses /etc/X11/xdm/Xservers; the KDE file may or may not be a link to that file.
   
3. Allow access; by default all accesss is denied. Again, for KDE and XDM, edit Xaccess in their respective directories; if you want global access add a single line:

   Code:

   *

   There are lots of comments in the file describing what you can do. Ignore stuff about the Chooser, though; you don't need that.
   

You should then be able to start your display manager and connect to it via XDMCP Direct or Broadcast, and get a login window.

There is more stuff that can be done with the basic (not-very-secure) X11 authentication mechanisms (for use after you sign on); post again if you want that.

[edwardb]

I just wanted to thank both of you for your input. The piece I was missing was the Xservers file. In retrospect it seems so obvious.

[paranode]

One thing you might want to do for security is tunnel over ssh. You should be able to do:

[smart]

I was lloking for help with XDMCP a while ago, this thread solved half of it. Thanks for that.
Would you also have a hint regarding running chooser like that ?
The idea in my case is, that i have a central smallbox (little resources) that should run a chooser and monitor the network for available servers running X. So at runtime it should bring up available servers into the chooser and remove them when the servers go down.
Cients shall always connect the central chooser first, do their choice and head on to the selected server.

[grant.mcdorman]

There are several things that you need to check to enable basic X11 authentication (that's MIT-MAGIC-COOKIE-1 authentication, which is very minimal - it would only keep away casual eavesdroppers).

In xdm (/etc/X11/xdm/xdm-config) the settings are:

• DisplayManager.DISPLAY.authorize should be True
  
• DisplayManager.DISPLAY.authName can be unset or MIT-MAGIC-COOKIE-1. (Our builds do not support the marginally more secure XDM-AUTHORIZATION-1.)
  
• DisplayManager.DISPLAY.authComplain should be True; when true, you'll see a message in the login window when authorization setup failed.
  
• DisplayManager.authDir should be the name of a directory only accessable by root; it will be used to temporarily store authentication keys for the servers.
  

DISPLAY can be a display number (e.g. 0 or 1) or a wildcard (i.e. *). All of this is documented in the xdm man page; however you're likely to be buried under the volume of (rather terse) information there.

The Gentoo defaults are:

• DisplayManager*authorize: true
  
• DisplayManager*authComplain: true
  
• DisplayManager*authName: the default value, MIT-MAGIC-COOKIE-1
  
• DisplayManager.authDir: the default value, /etc/X11/xdm/authdir
  

which are just fine for the standard Note also that Gentoo defaults to turning off XDMCP in xdm (see the end of the xdm-config file).

For KDM, there are similar settings in the kdmrc file, which will be in /usr/kde/3.1/share/config/kdm (provided you have installed KDE 3.1 or later). The default file is heavily commented; like XDM, XDMCP is disabled by default.

For GDM, there are the following items in /etc/X11/gdm/gdm.conf:

• under [daemon]: ServAuthDir=/var/lib/gdm - same as authDir.
  
• under [xdmcp]: Enable=true - enable XDMCP
  
• under [xdmcp]: HonorIndirect=true - allow XDMCP indirect queries (default is false)
  

Again, the file is heavily commented, and the defaults enable MIT-MAGIC-COOKIE-1 security.

Note that I strongly recommend you absolutely avoid doing any sort of bare XDMCP or X sessions over the Internet; neither XDMCP nor the X protocol itself are very secure at all. If you want to do X sessions over the Internet, you should use some sort of encrypted tunnel or VPN. Tunneling techniques include:

• ssh; this is well documented both in the Gentoo forums and elsewhere. However, you can't use XDMCP with this mode, as XDMCP messages cannot be forwarded by ssh (they're UDP).
  
• VNC [www.realvnc.com] or TightVNC [www.tightvnc.com], with the VNC traffic tunnelled through SSH. This becomes trickier to set up, however, if you want the VNC server to "log off" when the viewer disconnects (by default, it doesn't do this). I believe there are ways to do this, but I haven't looked into it.
  
• Zebedee [www.winton.org.uk/zebedee] with XDMCP. Zebedee is an encrypted tunneling program (like ssh provides); however, it can - with some limitations - also tunnel UDP traffic. The Zebedee manual includes a great deal of info about tunnelling VNC, since that's its primary target.
  

All of these applications have ebuilds.

I hope this is enough information; if not, post here again or drop me a line and I'll try to expand further.

Next: XDMCP Indirect - i.e. Chooser - sessions.