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.
Beispielhafte Ansicht aus Orbit SSH Manager. Hostnamen und Zahlen sind erfunden – die Oberfläche zeigt, wie die Informationen zusammenlaufen.
Ausgangslage
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.
Unangenehm wird das spätestens bei einem Audit oder einer Rückfrage der Geschäftsführung: Dann muss jemand sagen können, wer auf welchen Server zugreifen kann. Eine Liste dafür gibt es selten – nur die authorized_keys-Dateien, Host für Host.
Unser Lösungsweg
Alle Schlüssel an einer Stelle, ohne die Server umzubauen.
Orbit SSH Manager verbindet sich mit einem eigenen Schlüssel zu den eingebundenen Hosts, liest deren authorized_keys-Dateien und stellt sie zentral dar – je Host und je Benutzer. Änderungen nehmen Sie in der Oberfläche vor, der SSH Manager schreibt sie auf die Hosts zurück.
Auf den Zielsystemen wird dafür nichts installiert. Und wo ein Server nicht angefasst werden soll, legt man dort eine Sperrdatei ab – sie hat Vorrang vor dem Werkzeug.
Das Ergebnis
Die Frage „Wer kommt worauf?“ hat wieder eine Antwort.
- Verlässt jemand das Unternehmen, sehen Sie, auf welchen Hosts sein Schlüssel liegt, und entfernen ihn von einer Stelle aus – statt Server für Server auf der Kommandozeile.
- Ob das Aufräumen vollständig war, müssen Sie nicht schätzen: Über alle eingebundenen Hosts hinweg ist sichtbar, ob der Schlüssel noch irgendwo hinterlegt ist.
- Kommt die Rückfrage, wer auf welchen Server zugreifen kann, antworten Sie mit einer Übersicht statt mit einer Suche.
- Zugänge für Dienstleister oder ein einzelnes Projekt vergeben Sie gezielt – und nehmen sie genauso gezielt wieder zurück, wenn der Auftrag endet.
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.
Ebenfalls in Orbit
Die anderen Werkzeuge.
FAQ
Häufige Fragen zu Orbit SSH Manager.
Muss auf den verwalteten Hosts etwas installiert werden?
Wie verhindere ich, dass ein kritischer Host verändert wird?
Welche Anmeldeverfahren gibt es?
Welche Datenbank wird benötigt?
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.
Persönlich für Sie da
Wim Bonis
Technischer Leiter (CTO)