The environment at the moment is a selection of windows and Linux (RHEL 4/5 and SLES 10/11) whereby VNC access to the windows boxes works using ultravnc and providing a username/password combination to authenticate.
What is desirable is to use VNC to gain access to the Linux servers with authentication (before the console is displayed) being handled via a username/password combination.
I know that using VNC it is possible to handle this with a generic password or no password at all.
What is the best solution in this case? Is it possible to configure VNC access as desired?
Also beneficial would be having authentication done via pam so that pam_access and other restrictions are used.
Thanks,
Matt.
The solution is to use 'passwordless' vnc clients pointing to xdm sessions. Most examples of setting this up map explicit displays to ports using [x]inetd - but if you run vncserver with the -query option, it will find a free screen using XDMCP (assuming you've configured X/K/Gdm to run multiple instances).
See this document for a description of the setup from scratch - or this one for some shortcuts on centos (should also work on rhel)
RealVNC Enterprise Edition offers "System Authentication" which includes PAM support. It also supports strong encryption.
VNC servers on Linux create desktops with the privileges of the person who starts the server. While this is obvious when you're using displaying the screen of the person logged in sitting at the console (RealVNC's x0vncserver, or X11vnc, krfb or vino) it holds true for the virtual desktops as well.
If I wanted to log in as myself to a virtual VNC desktop, I would need to ssh in, start a virtual vncserver instance, then connect to that vncserver. Since I've done all that, why not just use a normal vncserver and tunnel connections to it over the ssh I just logged in with?
Although this doesn't directly answer your question about VNC authentication, perhaps a more appropriate solution for your problem would be NX.
Google has released a decent open source NX server in the form of neatx or alternatively there is FreeNX which is also open source but somewhat more complicated and shell scripted in it's implementation. I've had better success with neatx. And of course, there is always the commercial NX server, from the protocol originators NoMachine. The "free" NoMachine NX server is unsuitable for most normal production systems due to limitations (concurrent and number of unique users both = 2) but if you want to pay, those limitations are removed.
Next is the client. My best experience is still with the NoMachine client but I haven't yet tried OpenNX, it was just QtNX that didn't totally satisfy me. Like the server, the NoMachine NX client is only pseudo-free, but there aren't any annoying limitations beyond the license.
Again, it's not exactly what you asked but perhaps a solution worth considering.