Apache Guacamole ist ein clientless Remote-Desktop-Gateway, das den Zugriff auf entfernte Systeme per RDP, VNC, SSH und Telnet rein im Browser bereitstellt: über HTML5, ohne installierten Client, ohne Plugin und ohne Agent auf dem Endgerät. Ein moderner Browser genügt. Guacamole ist freie Software unter der Apache-Lizenz 2.0 und wird von der Apache Software Foundation gepflegt. Damit lässt es sich selbst hosten und als souveränes, mandantenfähiges Zugangsportal für verteilte Anlagen, Server und IoT-Geräte betreiben, ohne dass Maschinen oder Server jemals direkt aus dem Internet erreichbar sein müssen.
Wie Apache Guacamole funktioniert
Guacamole trennt sauber zwischen Web-Oberfläche und Protokoll-Verarbeitung. Zwei Komponenten greifen ineinander:
- guacd (der Daemon): das Herzstück. guacd ist ein nativer Proxy-Dienst, der die eigentlichen Remote-Desktop-Protokolle (RDP, VNC, SSH, Telnet, Kubernetes) als Plugins lädt und im Auftrag des Nutzers eine Verbindung zum Zielsystem aufbaut. Er übersetzt diese Protokolle in das schlanke Guacamole-Protokoll.
- guacamole-client (die Webapp): eine Java-Webanwendung, die in einem Servlet-Container wie Apache Tomcat läuft und Weboberfläche sowie Authentifizierung bereitstellt. Sie implementiert selbst kein einziges Remote-Protokoll, sondern reicht das Guacamole-Protokoll zwischen Browser und guacd durch.
Im Browser läuft ein in JavaScript geschriebener Client, der ausschließlich HTML5 und offene Standards nutzt. Er verbindet sich über HTTP(S) zurück zur Webapp und tauscht das Guacamole-Protokoll aus. guacd und seine Protokoll-Plugins teilen sich eine gemeinsame Bibliothek, libguac, die die Kommunikation abstrahiert. Für den Anwender bedeutet das: Tastatur, Maus und Bildschirm des entfernten Systems erscheinen im Browser-Tab, mehr ist auf dem Endgerät nicht nötig.
Architektur im Überblick
Ein produktives Guacamole-Setup besteht aus wenigen, klar abgegrenzten Schichten:
- Reverse-Proxy mit TLS (z. B. nginx oder Traefik) terminiert HTTPS und ist der einzige von außen erreichbare Punkt.
- guacamole-client im Tomcat liefert Oberfläche und Authentifizierung aus.
- guacd baut die eigentlichen Protokoll-Verbindungen ins interne Netz auf.
- Eine Datenbank (MariaDB/MySQL oder PostgreSQL) speichert Nutzer, Verbindungsdefinitionen, Rechte und Verbindungshistorie.
- Die Zielsysteme (Server, HMIs, Steuerungen) liegen im internen Netz und sind selbst nicht aus dem Internet erreichbar.
Der entscheidende Sicherheitsvorteil dieser Architektur: Das Zielsystem spricht nur mit guacd im selben Netz. Nach außen ist ausschließlich das Gateway sichtbar. RDP-, VNC- oder SSH-Ports müssen nirgends ins Internet geöffnet werden.
Für den Betrieb gibt es zwei Wege. Klassisch wird Guacamole nativ installiert (guacd plus Webapp im Tomcat). In der Praxis verbreiteter ist die containerisierte Variante: Die offiziellen Docker-Images (guacd und guacamole) lassen sich zusammen mit einer Datenbank in wenigen Schritten ausrollen und sauber versionieren. Beides eignet sich für den produktiven Einsatz, die Container-Variante vereinfacht Updates und Reproduzierbarkeit.
Aktuelle Version
Die aktuelle stabile Version ist Apache Guacamole 1.6.0, veröffentlicht am 22. Juni 2025 (Quelle: Apache Guacamole Release-Archiv). Version 1.6.0 brachte unter anderem verbesserte Rendering-Performance, besseren Docker-Support, konfigurierbare Groß- und Kleinschreibung bei Benutzernamen sowie Unterstützung für Duo v4. Server- (guacamole-server) und Client-Komponente (guacamole-client) werden gemeinsam unter derselben Versionsnummer veröffentlicht.
Sicherheit: Authentifizierung, MFA und kein exponiertes Zielsystem
Guacamole ist über Erweiterungen flexibel an bestehende Identitäten anzubinden:
- Authentifizierung: lokale Datenbank, LDAP/Active Directory.
- Mehr-Faktor (MFA): TOTP (z. B. Google Authenticator, Aegis) und Duo.
- Single Sign-on (SSO): SAML 2.0, OpenID Connect (OIDC), CAS sowie RADIUS.
Dazu kommen die genannten architektonischen Schutzmaßnahmen: Betrieb hinter Reverse-Proxy und TLS, keine direkt exponierten Zielsysteme und eine vollständige Verbindungshistorie. Optional lassen sich Sitzungen aufzeichnen. Ein wichtiges Detail: Die Zugangsdaten zu den Zielsystemen liegen serverseitig in der Guacamole-Datenbank und werden nicht an den Browser durchgereicht. Der Anwender authentifiziert sich am Gateway, nicht am einzelnen Server, und sieht die hinterlegten Passwörter der Zielsysteme nie. Wer Fernzugriff sauber nach dem Least-Privilege-Prinzip absichern will, kombiniert Guacamole mit rollenbasiertem Zugriff und revisionssicherem Audit, wie wir es im Artikel RBAC und Audit für Fernzugriff beschreiben. Für regulierte Umgebungen ist das die Grundlage eines NIS2-konformen Fernzugriffs.
Typische Einsatzfälle
- Industrieller HMI-Zugriff: Bedienoberflächen von Maschinen und Anlagen per VNC oder RDP direkt im Browser erreichen, ohne Software auf dem Servicegerät. Mehr dazu unter VNC im Browser.
- Jump-Host / Bastion: Guacamole als zentraler, protokollierter Einstiegspunkt in geschützte Netze, statt verstreuter VPN-Zugänge.
- Remote-Support und externe Dienstleister: zeitlich begrenzter, protokollierter Zugriff für Lieferanten und Maschinenbauer, ohne dauerhafte VPN-Clients.
- Kubernetes: direkter Zugriff auf die Konsole innerhalb eines Containers über die Kubernetes-Anbindung.
In unserer Case Study ABCO Water Systems zeigen wir, wie browserbasierter Fernzugriff für verteilte Wasseraufbereitungsanlagen in Australien produktiv betrieben wird, inklusive HMI-Zugriff und sicherer Standortanbindung per WireGuard.
Open Source: Apache-2.0-Lizenz
Guacamole steht unter der Apache License 2.0 und ist damit dauerhaft kostenfrei nutzbar, ohne Gebühren pro Nutzer oder Endgerät. Als Projekt der Apache Software Foundation ist der Quellcode offen, prüfbar und ohne Vendor-Lock-in einsetzbar. Das ist der Kern souveräner Fernwartung: Sie betreiben das Gateway auf eigener oder gemieteter Infrastruktur und behalten die volle Kontrolle über Zugänge und Daten.
Apache Guacamole vs. TeamViewer und AnyDesk
| Apache Guacamole | TeamViewer / AnyDesk | |
|---|---|---|
| Betriebsmodell | Self-hosted im eigenen Netz | SaaS über Anbieter-Cloud |
| Lizenz | Apache 2.0, kostenfrei | proprietär, pro Gerät/Seat |
| Datenhoheit | vollständig, eigene Infrastruktur | beim Anbieter |
| Client am Endgerät | nur Browser (HTML5) | App-Installation nötig |
| Protokolle | RDP, VNC, SSH, Telnet, Kubernetes | proprietär |
| Mandantenfähigkeit | ja, mit RBAC kombinierbar | begrenzt |
| Souveränität / NIS2 | im eigenen Rechenzentrum steuerbar | abhängig vom Anbieter |
TeamViewer und AnyDesk sind schnell eingerichtet, leiten Verbindungen aber durch die Cloud des Anbieters und binden Sie an dessen Preise und Standorte. Sobald Datenhoheit, Mandantenfähigkeit oder Compliance-Anforderungen ins Spiel kommen, ist ein selbst gehostetes Gateway wie Guacamole die tragfähigere Wahl.
Apache Guacamole souverän betreiben
Guacamole ist ein starker Baustein, aber ein produktives Betreiberportal braucht mehr: gehärtete Konfiguration, SSO-Anbindung, RBAC, Audit, sichere Standortanbindung und einen verlässlichen Betrieb inklusive CVE-Monitoring. Genau das bauen und betreiben wir als Remote-Management-Plattform, produktiv bewiesen bei ABCO Water Systems und nextGYM. Wird für den Netzzugang ein Mesh-VPN benötigt, betreibt WZ-IT es als Managed NetBird ab 349,90 € netto im Monat; das Basispaket enthält Monitoring, Updates, Backups und Support.
Dieser Beitrag ist allgemeine Information und keine Rechtsberatung. Für die konkrete Bewertung von NIS2- oder IEC-62443-Anforderungen ziehen Sie bitte fachkundigen Rat hinzu.
