SSH ohne Bastion und ohne Schlüsselverteilung

Üblicherweise erreicht man eine Serverflotte über SSH mit einer Bastion und einem Weg, öffentliche Schlüssel auf jeden Host zu bekommen - ein Lauf des Konfigurationsmanagements oder eine authorized_keys-Datei, die jemand von Hand bearbeitet. Beides wird mit der Zeit zum Problem: Die Bastion ist ein dauerhaft offener Port, und die Schlüsseldateien laufen dem tatsächlichen Personalstand hinterher.

Der CLI-Agent kann selbst einen SSH-Server betreiben. Er lauscht auf TCP 24822 an der Overlay-Adresse des Geräts, also an seiner Adresse innerhalb von SXAccess. Seine autorisierten Schlüssel sind die SSH-Schlüssel der Geräte, mit denen eine Zugriffsregel dieses Gerät verbindet, gleich in welcher Richtung. Auf einem Routing-Gerät eines Netzwerks gehören auch alle Geräte dazu, die eine Zugriffsregel eine seiner Ressourcen erreichen lässt. Die Schlüssel stammen aus der Netzwerkbeschreibung des Geräts, der Liste der Geräte und Routen, die der Management-Dienst auf jedem Gerät aktuell hält. Verbindet keine Zugriffsregel mehr ein anderes Gerät mit diesem, entfernt die nächste Aktualisierung den Schlüssel des anderen Geräts.

Der Server akzeptiert nur interaktive Terminalsitzungen: keine entfernten Befehle, kein scp oder sftp, keine Portweiterleitung. Dafür nutzen Sie den eigenen sshd des Hosts.

sxaccess shell gleicht zuerst den Host-Schlüssel des Ziels mit dem Schlüssel ab, den SXAccess für dieses Gerät verteilt. Eine Rückfrage, ob Sie dem Host vertrauen, gibt es bei der ersten Verbindung nicht, und ein Host mit einem anderen Schlüssel oder eine Adresse, die zu keinem Gerät gehört, wird abgewiesen.

• Die Bastion. Es gibt keinen öffentlichen SSH-Port, den Sie freigeben müssten: Der Server lauscht nur an der Overlay-Adresse des Geräts, jede Sitzung läuft also innerhalb von SXAccess.
• Die Schlüsselverteilung. Autorisierte Schlüssel pflegt SXAccess anhand der Netzwerkbeschreibung statt eines Laufs des Konfigurationsmanagements.
• Die Checkliste für Ausscheidende. Sperren Sie ein Mitglied, laufen alle Geräte, die es per Anmeldung registriert hat, sofort ab und werden getrennt. Entfernen Sie es danach aus der Organisation, werden diese Geräte gelöscht, und ein gelöschtes Gerät verschwindet aus jeder Netzwerkbeschreibung, mitsamt seinem SSH-Schlüssel. Siehe Offboarding.

• Den eigenen SSH-Dienst des Hosts weiterhin vom Internet fernhalten. SXAccess macht einen öffentlichen Port überflüssig; es schließt keinen, den Sie offen gelassen haben.
• Das Konto nennen. Geben Sie jedes Mal user@ mit einem persönlichen oder einem Rollenkonto an, damit die eigenen Protokolle des Ziels zeigen, wer sich angemeldet hat.
• SSH Access dort abschalten, wo niemand es braucht. Der Server läuft nur, solange beide Schalter an sind.

• Enabling the SXAccess SSH server requires root. Um den Server zu erlauben, sind auf dem Zielgerät Root-Rechte nötig. Die Meldung schlägt zwei sudo-Befehle vor; führen Sie stattdessen sudo sh -c 'sxaccess stop && sxaccess start --allow-server-ssh' als eine Zeile aus, wie in Schritt 1.
• This device is already connected, und SSH funktioniert trotzdem nicht. Solange das Gerät verbunden ist, übernimmt start keine Einstellungen; siehe start. Starten Sie den Agenten mit der Option neu: sudo sh -c 'sxaccess stop && sxaccess start --allow-server-ssh'. Führen Sie es als eine Zeile aus: Eine Verbindung über SXAccess, etwa eine SSH-Sitzung zu dieser Maschine, bricht ab, bis start fertig ist.
• error: this command needs Administrator rights. Auch sxaccess shell braucht auf Ihrem eigenen Gerät Root-Rechte. Starten Sie den Befehl mit sudo.
• SSH connection failed, und sxaccess info -d führt das Zielgerät nicht auf. Keine Zugriffsregel verbindet Ihr Gerät mit ihm. Legen Sie die Regel aus Schritt 3 an, oder prüfen Sie, ob Ihr Gerät zur Quellgruppe der Regel gehört.
• SSH connection failed, und das Zielgerät wird aufgeführt. Dort läuft der Server nicht. Prüfen Sie unter Devices, ob das Zielgerät online ist und ob SSH Access eingeschaltet und gespeichert ist. Auf dem Zielgerät muss der Agent mit --allow-server-ssh und ohne --block-inbound laufen. Um diese Sperre aufzuheben, führen Sie sxaccess stop && sxaccess start --block-inbound=false aus. Führen Sie es als eine Zeile aus: Eine Verbindung über SXAccess, etwa eine SSH-Sitzung zu dieser Maschine, bricht ab, bis start fertig ist.
• Das Zielgerät läuft unter Windows oder nutzt eine der Apps. Dort gibt es den Server nicht: Er läuft nur mit dem CLI-Agenten unter Linux und macOS.