Orbit

Orbit SSH Manager

Wer hat eigentlich Zugriff auf welchen Server?

SSH-Zugänge wachsen still: ein Schlüssel für den Dienstleister, einer für die Migration, einer für den Kollegen, der das Projekt inzwischen abgegeben hat. Verteilt über Dutzende authorized_keys-Dateien lässt sich kaum noch beantworten, wer worauf zugreifen kann. Orbit SSH Manager macht diese Dateien über alle Hosts hinweg sicht- und pflegbar.

ssh.ihre-domain.de
HostsHost suchen
HostABTKSVDLZustand
web-01gepflegt
db-01schreibgeschützt
backup-01gepflegt
legacy-02deaktiviert
mail-01gepflegt
app-04gepflegt
authorized_keys werden gelesen · app-0414 / 18

Beispielhafte Ansicht aus Orbit SSH Manager. Hostnamen und Zahlen sind erfunden – die Oberfläche zeigt, wie die Informationen zusammenlaufen.

Worum geht es?

Der Schlüssel ist schnell verteilt. Zurückgenommen wird er selten.

Einen öffentlichen Schlüssel auf einen Server zu legen dauert eine Minute. Ihn von zwanzig Servern wieder zu entfernen, wenn jemand das Unternehmen verlässt, ist ein Nachmittag Handarbeit – und niemand weiß hinterher sicher, ob es vollständig war. Orbit SSH Manager liest die authorized_keys-Dateien aller eingebundenen Hosts, stellt sie zentral dar und schreibt Änderungen von dort aus zurück.

Was das Werkzeug kann

Die Funktionen im Überblick.

Schlüssel über alle Hosts hinweg

Die authorized_keys-Dateien aller eingebundenen Hosts an einer Stelle – lesbar, durchsuchbar und pflegbar, statt Host für Host über die Kommandozeile.

Zugriff je Benutzer nachvollziehen

Sichtbar machen, welcher Schlüssel auf welchem Host für welchen Benutzer hinterlegt ist – die Grundlage, um beim Ausscheiden vollständig aufzuräumen.

Schutz gegen ungewollte Änderungen

Eine Datei .ssh/system_readonly auf dem Host sperrt jede Änderung durch den SSH Manager, .ssh/user_readonly nur für einen bestimmten Benutzer. Beide nehmen eine Begründung auf, die in der Oberfläche angezeigt wird.

Hosts stilllegen

Ein Host lässt sich in der Oberfläche deaktivieren – dann bleiben alle SSH-Operationen darauf aus. Praktisch für Wartungsfenster und für Systeme auf dem Weg in den Ruhestand.

Anmeldung und Rechte

Zugang über eine htpasswd-Datei mit bcrypt-Hashes, Sitzungen über JWT. Alle Schnittstellen außer der Anmeldung selbst verlangen ein gültiges Token.

Ausschließlich schlüsselbasiert

Der Server verbindet sich zu den verwalteten Hosts nur mit einem eigenen SSH-Schlüssel. Passwörter der Zielsysteme werden nicht benötigt und nicht gespeichert.

Datenhaltung nach Wahl

Standardmäßig eine SQLite-Datei, über die Konfiguration auf eine andere Datenbank umstellbar. Schema-Änderungen laufen als Migrationen beim Start.

Ein Container

Oberfläche, Schnittstelle und Webserver stecken in einem einzigen Abbild: nginx liefert die Anwendung aus und reicht die Schnittstellenaufrufe intern weiter.

Auf den Punkt

Was die Umsetzung ausmacht.

  • Die authorized_keys-Dateien bleiben das, was sie sind – es kommt kein Agent und kein zusätzlicher Dienst auf die verwalteten Hosts.
  • Die Sperrdateien liegen auf dem Zielsystem, nicht in der Anwendung: wer den Host besitzt, behält das letzte Wort.
  • Zugriffs- und Aktualisierungs-Token sind unterschiedliche Typen und nicht gegeneinander austauschbar.
  • Ein fertiges Container-Abbild steht in der GitHub Container Registry bereit.

Technik

Worauf Orbit SSH Manager aufsetzt.

Damit Sie einschätzen können, was der Betrieb bei Ihnen bedeutet – und was Sie im Quelltext erwartet.

Oberfläche
React 19 mit TypeScript, Tailwind CSS und Vite
Backend
Python 3.12 mit FastAPI und SQLAlchemy
Datenbank
SQLite als Standard, über DATABASE_URL austauschbar
Anmeldung
htpasswd mit bcrypt, JWT nach HS256
SSH
asyncssh, ausschließlich schlüsselbasiert
Lizenz
Business Source License 1.1

Aus der Praxis entstanden

Zugriffsverwaltung ist Alltag im Systembetrieb – Orbit SSH Manager ist das Werkzeug, mit dem wir sie in unseren Administrationsleistungen abbilden.

Zu Administration as a Service

FAQ

Häufige Fragen zu Orbit SSH Manager.

Muss auf den verwalteten Hosts etwas installiert werden?
Nein. Der SSH Manager verbindet sich per SSH mit seinem eigenen Schlüssel und bearbeitet die vorhandenen authorized_keys-Dateien. Es gibt keinen Agenten und keinen zusätzlichen Dienst auf dem Zielsystem.
Wie verhindere ich, dass ein kritischer Host verändert wird?
Über zwei Dateien auf dem Host selbst: .ssh/system_readonly sperrt jede Änderung durch den SSH Manager, .ssh/user_readonly sperrt sie für einen bestimmten Benutzer. Beide können eine Begründung enthalten, die in der Oberfläche erscheint. Alternativ lässt sich ein Host in der Oberfläche deaktivieren, dann unterbleiben alle SSH-Operationen darauf.
Welche Anmeldeverfahren gibt es?
Die Benutzerkonten liegen in einer htpasswd-Datei mit bcrypt-Hashes; angemeldete Sitzungen laufen über JWT. Zu den verwalteten Hosts verbindet sich der Server ausschließlich schlüsselbasiert – Passwörter der Zielsysteme kommen nicht vor.
Welche Datenbank wird benötigt?
Im Standard eine SQLite-Datei, was für kleinere Installationen genügt. Über die Variable DATABASE_URL lässt sich eine andere von SQLAlchemy unterstützte Datenbank einsetzen; Schema-Änderungen laufen beim Start automatisch als Migration.

Kontakt

Orbit SSH Manager unverbindlich anfragen

Sie möchten ein konkretes Angebot, eine Demo oder haben Fragen zur Migration? Schreiben Sie uns – wir melden uns in der Regel innerhalb eines Werktags.

DSGVO-konform
Hosting im eigenen RZ in Deutschland · AVV nach Art. 28 DSGVO
Terminwunsch (optional)