Zusammenfassung

  • SSH_MSG_CHANNEL_WINDOW_ADJUST erlaubt weitere Bytes auf einem SSH-Kanal; die Nachricht bestätigt weder deren Verarbeitung durch einen Befehl noch dessen Abschluss.
  • Antwort auf exec, optionaler Exit-Status, EOF und beidseitiger Schließvorgang kennzeichnen verschiedene Zeitpunkte und ersetzen kein dauerhaftes Anwendungsergebnis.
  • Für folgenreiche Operationen müssen eine idempotente Identität und eine Abfrage des Fernzustands die SSH-Sitzung überleben, damit ein Abbruch nicht zum blinden Wiederholen zwingt.

Vier Zustände hinter einer grünen Anzeige

Nutzer einer Fernsteuerung wollen wissen, ob etwas funktioniert hat. Das Protokoll beantwortet mehrere kleinere Fragen: Wurde der Kanal geöffnet? Hat der Server die exec-Anfrage angenommen? Darf der Sender weitere Daten übertragen? Meldete der entfernte Prozess einen Exit-Status? Haben beide Seiten ihren Kanal geschlossen?

Die Trennung hat praktische Folgen. Eine Startanfrage kann angenommen werden und später scheitern. Bytes können weiterlaufen, obwohl das Programm sie noch nicht verarbeitet. Ein Prozess kann Arbeit an eine Warteschlange übergeben und dann enden. Nach einer dauerhaften Änderung kann die Verbindung abbrechen, bevor der Nachweis den Client erreicht.

Ein belastbares Betriebsmodell hält deshalb vier Zustände auseinander: Anfrageannahme, Flussguthaben des Kanals, Prozessende und dauerhaftes Anwendungsergebnis. SSH macht die ersten drei beobachtbar. Das vierte muss die entfernte Anwendung definieren.

Was das Kanalfenster tatsächlich gewährt

Abschnitt 5.2 von RFC 4254 definiert das Fenster in Bytes. Es legt fest, wie viel die Gegenseite senden darf, bevor sie auf eine Anpassung warten muss. SSH_MSG_CHANNEL_WINDOW_ADJUST nennt Empfängerkanal und zusätzliche Bytezahl. Normale und erweiterte Daten, etwa Standardfehler, verbrauchen dasselbe Guthaben.

Das ist ein Flusskontrollvertrag. Seine Felder enthalten Kanal und Menge, aber keine Befehlskennung, keinen Anwendungszustand, kein Persistenzmerkmal und kein Resultat. Die Norm legt auch nicht fest, welches interne Pufferereignis eine Anpassung auslösen muss. Diese Kopplung bleibt der Implementierung überlassen.

Die Nachricht zeigt somit Bereitschaft für mehr Kanalverkehr. Sie zeigt nicht, dass ein bestimmtes Byte SSH-Bibliothek, Betriebssystem, gestarteten Prozess und nachgelagerten Dienst durchlaufen hat. Das Fenster schützt vereinbarte Kapazität; es führt kein Wirkungsjournal.

Startannahme ist kein Abschluss

Kanalspezifische Anfragen besitzen einen eigenen Rückkanal. Ist want reply gesetzt, antwortet der Empfänger mit Erfolg, Fehlschlag oder einer anfragespezifischen Fortsetzung. exec bittet den Server, den angegebenen Befehl zu starten; RFC 4254 empfiehlt, eine Antwort anzufordern und zu prüfen.

Diese Antwort trennt Annahme und Ablehnung. Der Lebenszyklus des Befehls beginnt aber erst. Kanalerfolg enthält weder den späteren Exit-Code noch die dauerhafte Objektkennung, die eine Anwendung möglicherweise anlegt.

Wenn Bibliotheken dieses Ereignis ohne Ebenenangabe „success“ nennen, klingt es endgültiger als es ist. Betriebsprotokolle sollten festhalten, was belegt wurde, und das Ereignis mit Sitzung, Kanal und Befehlsfingerabdruck verbinden.

Exit-Status: stärker, doch begrenzt

RFC 4254 definiert exit-status für die Zeit nach dem Ende des entfernten Befehls. Die Rückgabe ist empfohlen, nicht vorgeschrieben. Die Nachricht wird nicht quittiert, und der Client darf sie ignorieren. Null bedeutet laut Text gewöhnlich einen erfolgreichen Abschluss.

Für ein synchrones Programm, das erst nach erfülltem Auftrag mit Null endet, kann dies der richtige Endpunkt sein. Dieser Nachweis ist deutlich stärker als Byte-Guthaben.

Ein Wrapper kann jedoch schon nach dem Einreihen einer Aufgabe Null liefern. Eine Dienstverwaltung kann einen Neustart annehmen, bevor Gesundheit zurückkehrt. Ein Deployment kann die Steuerungsebene ändern, während Replikate noch konvergieren. SSH transportiert das Prozessergebnis; die Semantik des Programms erzeugt es nicht.

Kanalschluss beseitigt die Ungewissheit nicht

EOF besagt, dass eine Seite keine Daten mehr sendet. Es erhält keine ausdrückliche Antwort und schließt die Gegenrichtung nicht. Jede Seite darf close ohne vorheriges EOF senden. Ein Kanal gilt für eine Seite als geschlossen, wenn sie close gesendet und empfangen hat. Die Auslieferung früherer Daten an ihr Ziel wird nur empfohlen, sofern möglich.

Damit endet eine Kommunikationsressource geordnet. Es ist keine Garantie, dass jedes frühere Byte eine Wirkung ausgelöst hat. Ebenso beweist das fehlende letzte Signal nicht, dass keine Wirkung entstand. Ein Abbruch kann den Server mit bestätigter Änderung und den Client ohne Kenntnis davon zurücklassen.

Diese Ungewissheit als sicheren Fehlschlag zu behandeln und eine nicht idempotente Aktion zu wiederholen, erzeugt erst das Doppelereignis.

Sicherheitsgarantien bleiben in ihrer Schicht

RFC 4251 gliedert SSH in Transport, Benutzerauthentifizierung und Verbindung. RFC 4253 liefert Verschlüsselung, Serverauthentifizierung und Integrität; RFC 4252 authentifiziert den Benutzer auf Clientseite; danach multiplext die Verbindung logische Kanäle.

Diese Garantien beantworten, welcher Host verbunden ist, welcher Benutzer authentifiziert wurde und ob Daten geschützt reisten. Sie beantworten nicht, ob eine Migration commitete, ein Paket seinen Zielzustand erreichte oder eine delegierte API fertig wurde. Starke Authentifizierung macht Belege zurechenbar, erweitert aber nicht ihre Aussage.

Eine Operation mit längerer Lebensdauer als die Sitzung

Eine teure oder irreversible Aktion sollte eine Kennung besitzen, die SSH überlebt. Das entfernte System kann authentifizierte Identität, Ziel, Anfragefingerabdruck, Annahmezeit, Zustand, Endergebnis und erzeugtes Objekt daran binden. Der Client braucht nach erneuter Verbindung einen Abfrageweg.

Dafür ist keine neue SSH-Erweiterung nötig. Ein Kommandozeilenvertrag kann einen Idempotenzschlüssel annehmen, eine Operationskennung ausgeben und deren Status abfragbar machen. Bei Lesevorgängen oder bewiesener Idempotenz reichen Ausgabe und Exit-Code häufig. Der stärkere Vertrag gehört zu Aktionen, deren Wiederholung zwei Ressourcen erzeugt, Zugangsdaten zweimal rotiert oder eine Flotte erneut unterbricht.

Die Grundregel lautet: Fensteranpassung ist Byte-Guthaben, Anfrageerfolg ist Annahme, Exit-Status ist Prozessbeleg, close ist Kanalabschluss. Geschäftlicher Abschluss muss aus dem Geschäftsvorgang selbst kommen.

Quellen