SSH-Zugang

Diese Seite erklärt, wie Shell-Zugang zur Appliance gewährt wird. SSH-Zugang dient dem Hersteller-Support und dem Dateitransfer — er ist nicht Teil des täglichen Betriebs. Die textbasierte Bedienoberfläche (TUI) erledigt die Routineaufgaben direkt auf der Konsole, und SSH ist nur für jene Fälle vorgesehen, die die TUI nicht abdecken kann.

Warum es SSH-Zugang gibt

Die Pulse-Appliance ist so entworfen, dass 99 % aller Vorgänge über die TUI erledigt werden. Sie installieren Updates, verwalten TLS-Zertifikate, konfigurieren das Netzwerk und richten SFTP-Schlüssel ein, ohne jemals eine Shell zu öffnen. Das hält das System schmal und nachvollziehbar.

Es gibt zwei Situationen, in denen Shell-Zugang dennoch nötig ist:

• Hersteller-Support im Notfall. Wenn etwas unterhalb der TUI schiefläuft — ein Kernel-Problem, ein hängender Dienst, ein Fehler im Appliance-Image selbst — braucht ein Pulse-Support-Mitarbeiter eine Shell auf der Appliance, um zu untersuchen. SSH ist der Kanal dafür. Der Hersteller signiert ein kurzlebiges Zertifikat für den Schlüssel des Support-Mitarbeiters; Sie müssen im Voraus nichts bereitstellen.
• Der SFTP-Prinzipal pulse-transfer. Die Schlüssel, die Sie auf dem Bildschirm SFTP-Zugang verwalten, autorisieren eine externe Gegenseite, Dateien in das Austauschverzeichnis der Appliance abzulegen. Diese Gegenseite verbindet sich als pulse-transfer über denselben SSH-Dienst — die SFTP-Zustellung läuft also auf dem hier beschriebenen SSH-Stack.

In beiden Fällen vertraut die Appliance Zertifikaten, die von der SSH-Zertifizierungsstelle (CA) der Appliance signiert wurden. Auf der Appliance gibt es keine Liste einzelner Benutzerschlüssel zu pflegen — das Vertrauen ist an denjenigen delegiert, der den privaten CA-Schlüssel besitzt.

Die zwei Prinzipale

Jedes signierte Zertifikat trägt ein oder mehrere Prinzipale. Ein Prinzipal ist eine Kennung, anhand derer der SSH-Server entscheidet, welche Art von Zugang das Zertifikat gewährt. Die Appliance kennt genau zwei:

pulse — Bedienerrolle (SSH + TUI)

Wer sich als pulse anmeldet, landet in der Bediener-TUI. Das ist dieselbe Ansicht, die Sie auf der lokalen Konsole sehen. Von dort aus verwalten Sie Netzwerk, Zertifikate, Updates und so weiter. Der Benutzer pulse ist unprivilegiert: Er hat keine Root-Shell, kann keine Systemdateien direkt bearbeiten und die TUI nicht umgehen, um den Zustand der Appliance zu verändern. Alles, was geändert werden muss, läuft über die Menüs, die im Hintergrund privilegierte Wrapper aufrufen.

Verwenden Sie -n pulse, wenn Sie einen Schlüssel für einen Support-Mitarbeiter signieren, der die Appliance genauso bedienen soll, wie es der Bediener vor Ort tut.

pulse-transfer — nur SFTP

Der Prinzipal pulse-transfer autorisiert eine im chroot eingesperrte SFTP-Sitzung und nichts weiter: keine interaktive Shell, keine TCP-Weiterleitung, kein X11, keinen Tunnel. Der Inhaber eines pulse-transfer-Zertifikats kann Dateien in uploads/ ablegen und Dateien aus downloads/ abholen — das ist die gesamte ihm zur Verfügung stehende Oberfläche. Es ist der Prinzipal, der von den Schlüsseln genutzt wird, die Sie auf dem Bildschirm SFTP-Zugang eintragen.

Verwenden Sie -n pulse-transfer, wenn Sie einen Schlüssel signieren, dessen einzige Aufgabe das Übertragen von Dateien in und aus dem Austauschverzeichnis ist.

Ein einzelnes Zertifikat kann beide Prinzipale gleichzeitig tragen, wenn dieselbe Person beide Rollen tatsächlich benötigt — zum Beispiel ein Support-Mitarbeiter, der während derselben Sitzung auch ein Update-Bundle hochladen wird.

Wie der Hersteller einen Kundenschlüssel signiert

Das Signieren geschieht außerhalb der Appliance, auf einer Workstation, die den privaten CA-Schlüssel verwahrt. Die Appliance sieht den privaten CA-Schlüssel nie; sie kennt nur den dazugehörigen öffentlichen Schlüssel als Vertrauensanker.

Der gesamte Ablauf:

1. Sie als Bediener (oder wer auch immer Zugang benötigt) erzeugen auf Ihrer Workstation ein SSH-Schlüsselpaar, sofern Sie noch keines haben. Der öffentliche Teil liegt unter ~/.ssh/id_ed25519.pub.
2. Sie übermitteln dem Hersteller diese .pub-Datei über einen passenden Kanal — E-Mail, Ticket-Anhang, sichere Kurznachricht. Der private Teil verlässt Ihren Rechner nicht.
3. Der Hersteller signiert den öffentlichen Schlüssel mit dem privaten CA-Schlüssel über ssh-keygen -s und wählt den Prinzipal, der dem zu gewährenden Zugang entspricht.
4. Der Hersteller schickt Ihnen die signierte Zertifikatsdatei zurück. Per Konvention heißt sie id_ed25519-cert.pub (derselbe Basisname wie der Schlüssel, mit angehängtem -cert).
5. Sie legen das signierte Zertifikat neben Ihren Schlüssel — üblicherweise unter ~/.ssh/id_ed25519-cert.pub. Der SSH-Client liest es beim nächsten Verbindungsaufbau automatisch ein.

Die vom Hersteller ausgeführten Signaturbefehle sind:

Bedienerrolle (Prinzipal pulse)

ssh-keygen -s /path/to/ca_private_key -I "description" -n pulse -V +365d ~/.ssh/id_ed25519.pub

SFTP-Transferrolle (Prinzipal pulse-transfer)

ssh-keygen -s /path/to/ca_private_key -I "description" -n pulse-transfer -V +365d ~/.ssh/id_ed25519.pub

Beide Prinzipale in einem Zertifikat

ssh-keygen -s /path/to/ca_private_key -I "description" -n pulse,pulse-transfer -V +365d ~/.ssh/id_ed25519.pub

In jedem Fall wird das signierte Zertifikat unter ~/.ssh/id_ed25519-cert.pub abgelegt und vom SSH-Client automatisch verwendet.

Der Schalter -I setzt eine frei wählbare Identität, die im Zertifikat festgehalten wird — nützlich für die Nachvollziehbarkeit. Eine kurze Beschreibung wie support-mitarbeiter-jane-2026-05 oder die Ticketnummer, die zur Signatur führte, ist die richtige Detailtiefe.

Gültigkeitsfenster

Der Schalter -V +365d in den obigen Beispielen begrenzt die Gültigkeit des Zertifikats auf ein Jahr ab Signaturzeitpunkt. Danach läuft das Zertifikat ab, und der SSH-Server lehnt es ab — auch wenn der zugrunde liegende Schlüssel unverändert ist.

Dieser Ablauf ist bewusst gewählt:

• Er begrenzt den Schaden, falls ein Schlüssel verloren geht. Ein entwendetes Zertifikat verliert von selbst seine Wirkung; niemand muss es suchen und widerrufen.
• Er erzwingt einen wiederkehrenden Signaturvorgang, der zugleich der natürliche Anlass ist, die Frage zu stellen: „Braucht diese Person den Zugang noch?"
• Er passt zum Betriebsrhythmus einer verwalteten Appliance: Ein Jahr ist lang genug, dass das erneute Signieren keine ständige Last ist, und kurz genug, dass längst ausgeschiedene Mitarbeiter keinen dauerhaften Zugang behalten.

Kürzere Fenster sind für einzelne Support-Einsätze sinnvoll — -V +1d oder -V +1w für einen einzigen Vorgang, nach dessen Ende das Zertifikat tot ist. Verwenden Sie kürzere Gültigkeiten, wenn der Zugang an eine konkrete Aufgabe gebunden ist; reservieren Sie das Ein-Jahres-Fenster für Schlüssel, die wiederholt benutzt werden.

Der Ablauf des Zertifikats ist unabhängig vom SSH-Schlüssel selbst. Der Schlüssel bleibt gültig; nur die Signatur darauf läuft ab.

Was der Bediener nicht erhält

Ein signiertes pulse-Zertifikat gewährt dem Benutzer eine Shell auf der Appliance, aber diese Shell ist dieselbe eingegrenzte Umgebung, in der auch der lokale Bediener arbeitet:

• Der Benutzer pulse ist unprivilegiert. Er hat kein sudo für beliebige Befehle. Er kann Systemkonfigurationsdateien nicht direkt bearbeiten, Systemdienste nicht aus der Shell neu starten und die geschützten Geheimnisse der Appliance weder lesen noch schreiben.
• Konfigurationsänderungen laufen über die TUI. Die TUI selbst ruft eine kleine Menge geprüfter privilegierter Wrapper auf, um den Zustand der Appliance zu ändern. Daran führt kein Weg vorbei.
• Ein pulse-transfer-Zertifikat ist noch enger gefasst: gar keine Shell, nur SFTP in das Austauschverzeichnis.

Mit anderen Worten: SSH-Zugang ist ein Weg, die Bedienerrolle aus der Ferne zu erreichen, kein Weg, darüber hinaus zu eskalieren. Wer den Zustand der Appliance ändern will, tut das weiterhin über die TUI — er sieht sie nur per SSH statt auf der lokalen Konsole.

Verwandte Bildschirme

• SFTP-Zugang — verwalten Sie die kundenseitigen SFTP-Schlüssel, die als pulse-transfer authentifiziert werden.
• TUI-Referenz — das Bedienermenü, in dem der pulse-Benutzer nach dem SSH-Login landet.
• Installation — die Erstkonfiguration, einschließlich des SSH-CA-Vertrauensankers, der signierte Zertifikate erst akzeptierbar macht.