KeyHelp: Berechtigungen für Kunden gezielt freigeben (DNS-Editor, SSH, Datenbank-Fernzugriff, Backup)
Welche Rechte KeyHelp-Kunden ab Werk haben, wie Sie DNS-Editor, SSH, Datenbank-Fernzugriff und Backup gezielt freigeben und was jede Freigabe auf dem Server bewirkt. Mit den nötigen Zusatzschritten für den Datenbankzugriff.
Geprüft am 01.10.2026 · für KeyHelp 26.1.1
Mit KI erstellt – redaktionelle Prüfung ausstehend
WerbelinksMit * markierte Links sind Werbelinks: Bei einem Kauf erhalten wir eine Provision, der Preis bleibt gleich. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen. Mehr dazu
KeyHelp gibt neuen Kunden ab Werk nur einen schmalen Satz an Rechten: FTP, PHP, Backup-Verwaltung, Datei-Manager, E-Mail Catch-All und den Zugang zum Panel. Alles, was tiefer in den Server greift, etwa der DNS-Editor, SSH oder der Fernzugriff auf Datenbanken, bleibt gesperrt, bis Sie es gezielt freigeben. Diese Anleitung zeigt, wo Sie diese Berechtigungen setzen, was jede davon technisch auf dem Server bewirkt und welche Zusatzschritte nötig sind, damit eine Freigabe überhaupt wirkt. Sie richtet sich an Administratoren, die einzelnen Kunden mehr erlauben wollen, ohne die übrigen Konten zu gefährden. Getestet wurde mit KeyHelp 26.1.1 unter Debian 12. Die Grundinstallation beschreibt die Anleitung KeyHelp installieren und absichern.
Voraussetzungen
- KeyHelp (getestet: 26.1.1 Build 3698, Debian 12.15), eingerichtet nach KeyHelp installieren und absichern.
- Ein bestehendes Kundenkonto, im Beispiel
kunde1mit Domainkunde1.example.deund Datenbankkunde1_db. - Administratorzugang zum Panel und für die Prüfungen SSH als root.
Die Berechtigungen gibt es in gleicher Form in Konto-Vorlagen. Wer feste Tarife pflegt, setzt sie dort einmal, siehe KeyHelp: Konto-Vorlagen als Hosting-Tarife.
Schritt 1: Den Reiter „Berechtigungen“ öffnen
Öffnen Sie „Benutzerverwaltung“ › „Kundenkonten“ und klicken Sie beim Kunden auf das Stiftsymbol. Im Bearbeiten-Formular wechseln Sie in den Reiter „Berechtigungen“. Dort stehen 15 Schalter: „FTP“, „PHP“, „Perl/CGI“, „SSH“, „Backup-Verwaltung“, „Datei-Manager“, „DNS-Editor“, „Domain-Sicherheit“, „E-Mail-Einstellungen der Domain“, „Zertifikatsverwaltung“, „Datenbank-Fernzugriff“, „E-Mail Catch-All“, „Hauptdomains löschen“, „Control Panel-Zugriff“ und „Kontaktdaten aktualisieren“.
Bei „Perl/CGI“ und „SSH“ blendet KeyHelp einen Warnhinweis ein: „Achtung! Der Kunde ist nicht auf sein Stammverzeichnis beschränkt.“ Das ist ernst zu nehmen, siehe Schritt 3. Für das Beispiel wurden „SSH“, „DNS-Editor“ und „Datenbank-Fernzugriff“ zusätzlich aktiviert, „Backup-Verwaltung“ war ab Werk schon an.
Verifizieren: Nach „Speichern“ meldet KeyHelp „Der Benutzer kunde1 wurde aktualisiert. Die Änderungen werden in wenigen Augenblicken wirksam.“ Die Werte stehen sofort in der KeyHelp-Datenbank:
mysql keyhelp -e "select ssh,dns_editor,db_remote_access,backup from users where username='kunde1'"
# ssh dns_editor db_remote_access backup
# 1 1 1 1Schritt 2: DNS-Editor freigeben und prüfen
Mit „DNS-Editor“ erscheint im Kundenmenü unter „Domains“ der Punkt „DNS-Editor“. Der Kunde sieht dort seine Zonen, etwa kunde1.example.de und die System-Domain, und kann über „Record hinzufügen“ Einträge vom Typ A, AAAA, CAA, CNAME, HTTPS, MX, NS, PTR, SRV und TXT anlegen. Typischer Anlass sind Verifizierungs-TXT-Einträge für Microsoft 365 oder Google.
Im Test legte kunde1 den Eintrag _test vom Typ TXT mit dem Wert "s-edv-dns-test" an. Nach etwa einer Minute stand er in der Zonendatei, die KeyHelp für den lokalen BIND schreibt:
grep _test /etc/bind/keyhelp_domains/kunde1.example.de
# _test 3600 IN TXT "s-edv-dns-test"
named-checkzone kunde1.example.de /etc/bind/keyhelp_domains/kunde1.example.de
# zone kunde1.example.de/IN: loaded serial 2026100101
# OKWichtig für die Praxis: Der Eintrag wirkt nur, wenn der Server tatsächlich autoritativer Nameserver der Domain ist. Liegt das DNS beim Registrar oder bei Cloudflare, ändert der Kunde im KeyHelp-Editor nur eine Zone, die niemand abfragt. Geben Sie den DNS-Editor deshalb nur Kunden, deren Domains auf Ihre Nameserver zeigen.
Verifizieren: In der Kundenansicht steht der Menüpunkt „DNS-Editor“, die Zonendatei enthält den neuen Eintrag und named-checkzone meldet „OK“.
Schritt 3: SSH freigeben und die Folgen kennen
Ohne SSH-Recht ist der Systembenutzer des Kunden Mitglied der Gruppe keyhelp_nossh und hat die Shell /bin/false. KeyHelp trägt diese Gruppe in die SSH-Konfiguration ein:
grep -n "DenyGroups\|Match Group" /etc/ssh/sshd_config
# 125:DenyGroups keyhelp_nossh keyhelp_suspended
# 127:Match Group keyhelp_chrootNach dem Aktivieren von „SSH“ entfernt KeyHelp den Kunden aus keyhelp_nossh und setzt /bin/bash als Shell:
getent passwd kunde1
# kunde1:x:5001:5001::/home/users/kunde1/:/bin/bash
id kunde1
# uid=5001(kunde1) gid=5001(kunde1) groups=5001(kunde1),1001(keyhelp_file_manager)Im Test konnte sich kunde1 danach per SSH anmelden. Er landete in /home/users/kunde1, konnte aber mit normalen Benutzerrechten auch außerhalb lesen, etwa das Verzeichnis /home/users mit den Kundenordnern oder /etc/os-release. Zugriff auf /root wurde verweigert. Genau davor warnt der Hinweis im Formular. Eine Einschränkung auf das eigene Verzeichnis bietet KeyHelp über die Gruppe keyhelp_chroot und die Einstellung „Eingeschränkte SSH-Umgebung“, die in der Oberfläche als „Pro-Feature“ markiert ist. Sie wurde nicht getestet.
Verifizieren: getent passwd kunde1 zeigt /bin/bash, und id kunde1 listet keyhelp_nossh nicht mehr.
Schritt 4: Datenbank-Fernzugriff in drei Ebenen freischalten
Das Recht „Datenbank-Fernzugriff“ allein reicht nicht. Im Test zeigte das Bearbeiten-Formular der Datenbank beim Kunden danach weiterhin nur Name, Benutzer, Beschreibung und Passwort. Erst mit der globalen Einstellung erscheint die Auswahl. Öffnen Sie dazu als Administrator „Konfiguration“ › „Datenbank-Server“ und aktivieren Sie „Fernzugriff erlauben“.
KeyHelp schreibt daraufhin /etc/mysql/mariadb.conf.d/99-keyhelp.cnf mit bind-address = *, MariaDB lauscht dann auf allen Adressen. Jetzt findet der Kunde unter „Datenbanken“ › Datenbank bearbeiten den Bereich „Fernzugriff“ mit drei Optionen: „Nur lokale Verbindungen zulassen.“, „Verbindungen von beliebigen Hosts zulassen.“ und „Erlaubt Remote-Verbindungen von einem oder mehreren angegebenen Hosts.“ Wählen Sie immer die dritte Option und tragen Sie die feste IP des Kunden ein, im Beispiel 198.51.100.10.
Die dritte Ebene ist die Firewall. Die KeyHelp-Firewall enthält ab Werk die Regel „MariaDB / MySQL“ mit der Aktion „Verweigern“ für TCP 3306. Daran ändert die globale Einstellung nichts, wie der Hilfetext selbst sagt. Ohne angepasste Regel bleibt der Port von außen geschlossen.
Verifizieren: MariaDB kennt nun einen zweiten Benutzer-Eintrag für die erlaubte IP, und ein Verbindungsversuch von einer anderen Adresse wird abgelehnt:
mysql -e "select user,host from mysql.user where user like 'kunde%'"
# kunde1_db 198.51.100.10
# kunde1_db localhost
iptables -S | grep 3306
# -A INPUT -p tcp -m tcp --dport 3306 -j DROP
Schritt 5: Backup-Verwaltung und Rechte wieder entziehen
„Backup-Verwaltung“ ist ab Werk aktiv und blendet beim Kunden den Menüpunkt „Backup“ unter „Einstellungen“ ein. Wie Sicherungen auf dem Server eingerichtet werden, beschreibt die Anleitung KeyHelp-Backups extern einrichten. Wenn Sie Backups ausschließlich zentral steuern wollen, schalten Sie das Recht ab.
Entzogen wird ein Recht genauso, wie es vergeben wurde: Häkchen entfernen und speichern. Im Test wurden „SSH“ und „DNS-Editor“ wieder abgeschaltet. Nach etwa einer Minute war kunde1 wieder in keyhelp_nossh mit Shell /bin/false, der SSH-Login scheiterte und das Systemprotokoll vermerkte „Failed password for invalid user kunde1“. Der direkte Aufruf des DNS-Editors führte zurück auf das Dashboard. Bereits angelegte DNS-Einträge blieben allerdings in der Zone stehen.
Verifizieren: id kunde1 listet wieder keyhelp_nossh. Prüfen Sie nach dem Entzug des DNS-Editors die Zone auf Einträge, die der Kunde hinterlassen hat.
Typische Fehler
Datenbank-Fernzugriff aktiviert, Kunde sieht keine Option
Das Kundenrecht allein bewirkt nichts Sichtbares. Ohne „Fernzugriff erlauben“ unter „Konfiguration“ › „Datenbank-Server“ zeigt das Datenbankformular des Kunden keinen Bereich „Fernzugriff“.
Fernzugriff eingerichtet, Verbindung kommt nicht an
Die Firewall-Regel „MariaDB / MySQL“ steht ab Werk auf „Verweigern“. Kommt die Verbindung durch, aber von einer nicht eingetragenen Adresse, antwortet MariaDB mit „Host '…' is not allowed to connect to this MariaDB server“. Diese Meldung erschien im Test bei einem Versuch von der Server-IP selbst.
SSH freigegeben in der Annahme, der Kunde sei eingesperrt
Der Kunde ist nicht auf sein Verzeichnis beschränkt und kann sich auf dem Server umsehen. Geben Sie SSH nur vertrauenswürdigen Kunden oder setzen Sie auf die eingeschränkte Umgebung der Pro-Edition.
Häufige Fragen
Wann greifen geänderte Berechtigungen?
In der KeyHelp-Datenbank sofort, auf dem System nach dem nächsten Lauf des KeyHelp-Cronjobs, der jede Minute läuft. Im Test dauerte es 30 bis 60 Sekunden.
Was ist „Hauptdomains löschen“?
Ohne dieses Recht kann der Kunde Hauptdomains nicht selbst entfernen. Ab Werk ist es aus, das schützt vor versehentlichem Löschen einer Website samt E-Mail.
Was regelt „Control Panel-Zugriff“?
Laut Keyweb-Dokumentation nur die Anmeldung des Kunden an der KeyHelp-Oberfläche. Der Administrator kann sich unabhängig davon über das Login-Symbol in der Benutzerverwaltung als Kunde anmelden.
Gibt es ein Protokoll über Änderungen des Kunden?
Ja. Im Kundenmenü unter „Protokolle“ › „Ereignis-Protokolle“ stand nach dem Test der Eintrag „DNS settings of domain kunde1.example.de (#2) updated.“ mit Datum, Benutzer und IP-Adresse. Auch Anmeldungen per Einmal-Login erscheinen dort als „User kunde1 logged in via Single-Sign-On.“ Für die Fehlersuche bei einer plötzlich nicht mehr erreichbaren Domain ist das der erste Blick.
Sollte ich jedem Kunden alle Rechte geben, damit weniger Support anfällt?
Besser nicht. Jedes zusätzliche Recht ist eine weitere Stelle, an der ein Kunde versehentlich etwas verstellen kann, etwa einen MX-Eintrag im DNS-Editor oder eine offene Datenbank. Vergeben Sie Rechte auf Anfrage und dokumentieren Sie, wem Sie was freigegeben haben. Ein gutes Muster sind zwei Konto-Vorlagen: eine schlanke für Website-Kunden und eine erweiterte für Agenturen oder Entwickler.
Testumfang
Getestet auf KeyHelp 26.1.1 unter Debian 12: DNS-Editor, SSH und Datenbank-Fernzugriff für einen Kunden freigegeben, Wirkung in Zonendatei, Benutzerkonto, SSH-Konfiguration und MariaDB geprüft, Rechte wieder entzogen. Auffällig ist der dreistufige Datenbank-Fernzugriff. Eine echte Verbindung von außen über die Firewall wurde nicht getestet. Prüfen Sie Freigaben immer auch auf Systemebene.
Fazit
Die Berechtigungen in KeyHelp sind fein genug, um jedem Kunden genau das freizugeben, was er braucht. Der Mehrwert liegt im Detail: Der DNS-Editor nützt nur bei eigenem Nameserver, SSH öffnet mehr als das Kundenverzeichnis, und der Datenbank-Fernzugriff braucht drei abgestimmte Einstellungen. Wer diese Zusammenhänge kennt, vergibt Rechte bewusst und vermeidet, dass ein harmloses Häkchen die Angriffsfläche des ganzen Servers vergrößert.
