I operate a hosting company, I've been operating it since 1985, initially as a Unix timeshare service, then I got access to Arpanet through somewhat shady means, basically I contracted with someone else who had gotten access through probably not legitimate means, but when the first public CIX was formed in February of 1991 (the Wiki said mid-1991 but we connected in February, we officially became an Internet provider.
Over the years, we dropped most access and focused on hosting, but also Linux shell accounts (early on it was Unix shell accounts, first Microsoft Xenix, then SCO Xenix, then SunOS 3.5, then 4.0, 4.1, so forth and around 1995 we started migrating off Sun/Sparc to Linux. Today we have shell servers for customers with many different flavors and currently offer access via ssh, x2go, rdp, and vnc, though usually the latter two are tunneled through SSH and x2go does that by default. We also offered access via the web using an ancient version guacamole. Not wishing to maintain a separate database for guac and with no method of tying it into system wide NIS based authentication (no pam module, etc) we just created a public/public login and password. Tacky but got us there. Then when the no-auth module came about we used that, much nicer, users were happy. Then I upgraded, and it broke, but I found the hack I mentioned earlier and applied it and all was well, until I upgraded to 1.5.2 and it broke again, and just changing the version number again did not fix.
So since this is functionality we've had for a number of years, I'd really like to get it working again and soon because users are screaming. I could just go back and re-install .92 or whatever it was but really want some of the functionality the later verison provides. If it could auth via NIS that would be great but I do NOT want to have to maintain a separate user database for guac, it will confuse customers because they'll change their password on a shell server but then the new password won't work on guac, etc. And I'm a one person operation supporting about 500 users, so I need to keep things reasonably efficient in terms of my own time.
Ideally I would like to have the web server actually authenticate via NIS but unfortunately some other modules I use in apache are not compatible with the external authentication modules.
On 7/30/23 17:29, Nick Couchman wrote:
You should not use the NoAuth plugin. There's a reason we deprecated it - disabling Guacamole's security completely - which is effectively what the NoAuth module did - is a bad idea. (I was once asking similar questions, trying to get the NoAuth module to work, so I do understand some of the situations where it seems like a good idea - e.g. I'm connecting to a RDP server also requires authentication, why should I have Guacamole do it for me and have users have to go through two layers of authentication? There are better answers to these questions than, "I don't need Guacamole security.") If you want to get your upstream proxy - like Apache httpd or nginx - to do the authentication, and pass that through to Guacamole, you should use the header plugin, which accepts an HTTP header (by default REMOTE_USER) with the name of a user and treats that as a valid authentication. https://guacamole.apache.org/doc/gug/header-auth.html You can combine the header authentication extension with some other extension - like JDBC - to store connections and then grant access to the connections to users who successfully authenticate via the header module, or something like the QuickConnect module to allow users to put in their own connection URIs and connect directly to a server (but be aware of the security risks of allowing that). If there's something else you're trying to do, or some reason you think that you need/want the NoAuth module, feel free to post back with that information and maybe we can suggest other ways to work with Guacamole's security rather than completely disabling it. -Nick --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
