KeyHelp: SSH- und SFTP-Zugang für Kunden freigeben und SSH-Schlüssel hinterlegen

Entwickler und Agenturen arbeiten lieber per SFTP und SSH als mit dem Datei-Manager im Browser. Im Test war SSH für den neu angelegten Kunden gesperrt. Diese Anleitung zeigt, wie der Admin den Zugang freigibt, wie der Kunde einen SSH-Schlüssel im Panel hinterlegt und was dabei auf dem Server passiert. Im Test zeigten sich drei Punkte, die Sie vorher kennen sollten: Der Kunde ist nicht auf sein Verzeichnis beschränkt, das Passwort funktioniert neben dem Schlüssel weiter, und von Hand eingetragene Schlüssel entfernte KeyHelp beim Löschen eines Schlüssels im Panel. Grundlage ist ein KeyHelp-Server wie in KeyHelp installieren und absichern.

Voraussetzungen

• KeyHelp-Server, getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.15 mit OpenSSH_9.2p1 Debian-2+deb12u10.
• Admin-Zugang zum Freigeben und ein Kundenkonto, im Beispiel kunde1 (Max Mustermann).
• SSH-Schlüsselpaar auf dem Rechner des Entwicklers. Im Test haben wir Schlüssel und Verbindungen auf dem Server selbst erzeugt und über 127.0.0.1 geprüft. Verbindungen von außen über die Firewall haben wir nicht getestet.

Schritt 1: SSH für den Kunden freigeben (Admin)

Ohne Freigabe hat der Systembenutzer des Kunden die Shell /bin/false und gehört zur Gruppe keyhelp_nossh. Diese Gruppe sperrt KeyHelp in der SSH-Konfiguration:

grep -vE "^\s*#|^\s*$" /etc/ssh/sshd_config

Subsystem	sftp	/usr/lib/openssh/sftp-server
DenyGroups keyhelp_nossh keyhelp_suspended
Match Group keyhelp_chroot
 ChrootDirectory %h
 AllowTCPForwarding no
 X11Forwarding no
Match all

Der Block Match Group keyhelp_chroot sperrt Mitglieder dieser Gruppe in ihr Home-Verzeichnis. Auf dem Testserver hatte die Gruppe kein Mitglied: keyhelp_chroot:x:1005:.

Als Admin öffnen Sie „Benutzerverwaltung“, bearbeiten den Kunden und wechseln auf den Reiter „Berechtigungen“. Beim Haken „SSH“ steht ein deutlicher Hinweis: „Achtung! Der Kunde ist nicht auf sein Stammverzeichnis beschränkt.“

Nach „Speichern“ meldete KeyHelp „Der Benutzer kunde1 wurde aktualisiert. Die Änderungen werden in wenigen Augenblicken wirksam.“ Bei der nächsten Kontrolle auf dem Server hatte der Benutzer eine Shell und war nicht mehr in keyhelp_nossh:

kunde1:x:5001:5001::/home/users/kunde1/:/bin/bash
uid=5001(kunde1) gid=5001(kunde1) groups=5001(kunde1),1001(keyhelp_file_manager)

Verifizieren: getent passwd kunde1 zeigt /bin/bash, id kunde1 listet keyhelp_nossh nicht mehr.

Schritt 2: Schlüsselpaar erzeugen

Der Entwickler erzeugt das Schlüsselpaar auf seinem eigenen Rechner, der private Schlüssel sollte ihn nie verlassen. Im Test haben wir einen Ed25519-Schlüssel ohne Passphrase erzeugt:

ssh-keygen -t ed25519 -N "" -C "agentur@example.de" -f /root/client/id_ed25519

Your public key has been saved in /root/client/id_ed25519.pub
The key fingerprint is:
SHA256:FP5MOnbjeVW2TwmH3C0iJXzh4STtHaw9teTMGHu0VuY agentur@example.de

Ins Panel gehört nur der Inhalt der Datei mit der Endung .pub.

Verifizieren: Der öffentliche Schlüssel ist eine einzige Zeile und beginnt mit ssh-ed25519.

Schritt 3: Öffentlichen Schlüssel im Panel hinterlegen (Kunde)

Erst nach der Freigabe bekommt der Kunde unter „Profil“ den Reiter „SSH-Schlüssel“. Ohne SSH-Recht zeigte das Profil im Test nur „Konto-Einstellungen“, „Kontaktdaten“, „Zwei-Faktor-Authentifizierung“ und „Web-Authentifizierung“. Mit „SSH-Schlüssel hinzufügen“ öffnet sich ein Formular mit „Name“ und „Öffentlicher Schlüssel“. Laut Hinweis beginnt ein öffentlicher Schlüssel „normalerweise“ mit ssh-rsa, ssh-ed25519 oder einer der drei ecdsa-sha2-nistp-Varianten.

Nach „Speichern“ meldete KeyHelp „Die Einstellungen wurden aktualisiert. Die Änderungen werden in wenigen Augenblicken wirksam.“ Die Liste zeigt Name, Fingerprint als „MD5“ und „SHA256“ und das Erstelldatum. Der Link „SHA256“ blendete denselben Fingerabdruck wie ssh-keygen ein.

Auf dem Server schreibt KeyHelp den Schlüssel mit dem Namen als Kommentar in die Datei authorized_keys:

-rw-------  1 kunde1 kunde1  124 Oct  1 20:08 authorized_keys
# Name: Agentur Laptop
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAINwYG0XoLr1v1vkkL/n+YZ70

Die Datei gehört dem Kunden und hat die Rechte 600, das Verzeichnis .ssh hat 700. Der Kunde kann sie per SSH selbst bearbeiten, siehe Schritt 6.

Verifizieren: cat /home/users/kunde1/.ssh/authorized_keys als root zeigt den Eintrag mit dem Namen aus dem Panel.

Schritt 4: Mit SSH und SFTP anmelden

Die Anmeldung mit dem Schlüssel haben wir so geprüft. BatchMode=yes verhindert eine Passwortabfrage, damit der Test wirklich nur den Schlüssel nutzt:

ssh -o BatchMode=yes -o PreferredAuthentications=publickey -i /root/client/id_ed25519 kunde1@127.0.0.1 "id; pwd; ls /home/users | head; cat /etc/os-release | head -1; ls /root"

uid=5001(kunde1) gid=5001(kunde1) groups=5001(kunde1),1001(keyhelp_file_manager)
/home/users/kunde1
kunde1
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
ls: cannot open directory '/root': Permission denied

Das Systemprotokoll vermerkt den Schlüssel mit seinem Fingerabdruck:

sshd[1899]: Accepted publickey for kunde1 from 127.0.0.1 port 38000 ssh2: ED25519 SHA256:FP5MOnbjeVW2TwmH3C0iJXzh4STtHaw9teTMG

SFTP braucht keine eigene Freigabe, es läuft über denselben Zugang:

printf "pwd\nls\nget /etc/os-release /tmp/os-release-per-sftp\nls /home/users\n" | sftp -b - -i /root/client/id_ed25519 kunde1@127.0.0.1

Remote working directory: /home/users/kunde1
sftp> ls
files  logs   tmp    www    
sftp> get /etc/os-release /tmp/os-release-per-sftp
sftp> ls /home/users
/home/users/kunde1  

Der Kunde landet in seinem Home-Verzeichnis, kann aber, wie der Hinweis im Panel warnt, auch außerhalb lesen: Im Test lud er per SFTP /etc/os-release herunter und listete /home/users. Das Verzeichnis /root blieb gesperrt (Permission denied, siehe oben). Auf dem Testserver gab es nur einen Kunden. Ob andere Kunden die Ordner ihrer Nachbarn unter /home/users sehen, haben wir deshalb nicht geprüft. Die Einschränkung auf das eigene Verzeichnis heißt in KeyHelp „Eingeschränkte SSH-Umgebung“. Die Seite meldete im Test „Diese Funktion ist ausschließlich in der Professional Edition von KeyHelp verfügbar.“ Laut KeyHelp-Website gehört eine „SSH chroot environment“ zu den Vorteilen von KeyHelp Pro. Die Funktion haben wir nicht getestet.

Verifizieren: Dateien, die der Kunde per SSH anlegt, gehören ihm: -rw-r--r-- 1 kunde1 kunde1 0 Oct 1 20:08 /home/users/kunde1/www/per-ssh.txt.

Schritt 5: Passwort bleibt aktiv

Ein hinterlegter Schlüssel schaltet die Passwortanmeldung nicht ab. Die wirksame SSH-Konfiguration erlaubt beides:

pubkeyauthentication yes
passwordauthentication yes

Im Test meldete sich kunde1 mit dem Panel-Passwort an, während der Schlüssel hinterlegt war. Das Protokoll zeigt beide Wege nebeneinander:

sshd[1962]: Accepted password for kunde1 from 127.0.0.1 port 57806 ssh2
sshd[2013]: Accepted publickey for kunde1 from 127.0.0.1 port 57822 ssh2: ED25519 SHA256:FP5MOnbjeVW2TwmH3C0iJXzh4STtHaw9teTMG

Eine Einstellung, um für Kunden nur Schlüssel zuzulassen, haben wir im Kundenformular nicht gefunden. Ein schwaches Panel-Passwort ist also auch ein schwacher SSH-Zugang. Ob ein serverweites Abschalten von PasswordAuthentication von KeyHelp überschrieben wird, haben wir nicht getestet.

Verifizieren: sshd -T | grep -E "^(passwordauthentication|pubkeyauthentication) " zeigt die wirksamen Werte.

Schritt 6: Schlüssel entfernen und Zugang entziehen

Den Schlüssel löscht der Kunde in der Liste über das Papierkorb-Symbol und bestätigt mit „Okay“. KeyHelp meldete „Die folgenden Elemente wurden gelöscht. Die Änderungen werden in wenigen Augenblicken wirksam.“ Bei der nächsten Kontrolle war authorized_keys leer:

-rw------- 1 kunde1 kunde1 0 Oct  1 20:10 authorized_keys

Vorher hatten wir per SSH einen zweiten Schlüssel von Hand an die Datei angehängt. Auch dieser war danach weg, beide Anmeldungen scheiterten:

kunde1@127.0.0.1: Permission denied (publickey,password).
Agentur-Schlüssel exit: 255
kunde1@127.0.0.1: Permission denied (publickey,password).
manueller Schlüssel exit: 255

Entzieht der Admin das Recht „SSH“, setzt KeyHelp die Shell zurück auf /bin/false und den Benutzer wieder in keyhelp_nossh. Für diesen Test war der Schlüssel „Agentur Laptop“ wieder in authorized_keys eingetragen. Nach dem Entzug stand er weiter in der Datei, die Anmeldung mit ihm scheiterte trotzdem, auch per SFTP. Das Systemprotokoll nennt den Grund:

sshd[2873]: User kunde1 from 127.0.0.1 not allowed because a group is listed in DenyGroups

Der Reiter „SSH-Schlüssel“ verschwindet dabei aus dem Profil des Kunden.

Verifizieren: Ein Anmeldeversuch mit dem Schlüssel endet mit Permission denied (publickey,password).

Typische Fehler

„Der angegebene öffentliche Schlüssel ist ungültig.“ Diese Meldung kam im Test, als im Feld nur der Base64-Teil ohne Typ stand. Kopieren Sie die komplette Zeile aus der .pub-Datei, beginnend mit ssh-ed25519 oder ssh-rsa.

„Permission denied (publickey,password).“ Im Test hatte das drei Ursachen: Das Recht „SSH“ fehlte (Protokoll: not allowed because a group is listed in DenyGroups), der Schlüssel war im Panel nicht hinterlegt, oder er war von Hand eingetragen und von KeyHelp überschrieben worden.

Von Hand ergänzter Schlüssel ist verschwunden. Beim Löschen eines Schlüssels im Panel hat KeyHelp im Test die ganze Datei authorized_keys neu geschrieben, den von Hand angehängten Schlüssel eingeschlossen. Andere Änderungen haben wir darauf nicht geprüft. Hinterlegen Sie Schlüssel deshalb nur über „Profil“, „SSH-Schlüssel“.

Häufige Fragen

Braucht SFTP eine eigene Freigabe?

Nein. SFTP läuft über den SSH-Dienst (Subsystem sftp /usr/lib/openssh/sftp-server). Mit dem Recht „SSH“ funktionierte im Test auch SFTP, ohne das Recht keines von beiden.

Kann der Admin Schlüssel für den Kunden hinterlegen?

Im Bearbeiten-Formular des Kunden haben wir dafür kein Feld gefunden, die Reiter heißen „Allgemein“, „Kontaktdaten“, „Ressourcen“, „Berechtigungen“, „PHP“, „PHP-FPM“ und „Erweiterte Einstellungen“. Getestet haben wir den Weg über den Kundenbereich.

Kann ich mehrere Schlüssel hinterlegen?

Wir haben nur einen Schlüssel über das Panel angelegt. Mehrere Schlüssel über das Panel haben wir nicht getestet.

Testumfang

Wir haben in KeyHelp 26.1.1 SSH für einen Kunden freigegeben, einen Ed25519-Schlüssel im Panel hinterlegt und gelöscht und Anmeldungen per SSH und SFTP mit Schlüssel und Passwort auf dem Server selbst über 127.0.0.1 geprüft. Auffällig: Einen von Hand eingetragenen Schlüssel entfernte KeyHelp beim Löschen im Panel, und das Passwort funktioniert weiter. Nicht getestet: Verbindungen von außen, mehrere Kunden auf einem Server und die Pro-Funktion „Eingeschränkte SSH-Umgebung“. Geben Sie SSH nur vertrauenswürdigen Kunden frei.

Fazit

SSH- und SFTP-Zugang ist in KeyHelp eine Sache von zwei Klicks: Haken beim Admin, Schlüssel beim Kunden. Die Technik dahinter ist schlicht und nachvollziehbar, Gruppe keyhelp_nossh und Shell steuern den Zugang, das Panel verwaltet authorized_keys. Planen Sie dabei ein, dass der Kunde in der getesteten Version ohne die Pro-Funktion nicht auf sein Verzeichnis beschränkt ist und dass ein Schlüssel das Passwort nicht ersetzt. Entziehen Sie das Recht „SSH“, sobald ein Projekt beendet ist. Im Test war die Anmeldung mit dem Schlüssel danach gesperrt, per SSH und per SFTP.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern
• KeyHelp: Berechtigungen für Kunden festlegen
• SSH-Hardening: sshd_config, Match-Blöcke und ssh-audit
• Keyweb: KeyHelp, alle Funktionen im Überblick