Résumé

  • SSH_MSG_CHANNEL_WINDOW_ADJUST autorise l’envoi d’un nombre supplémentaire d’octets sur un canal ; il ne confirme ni leur traitement par une commande, ni l’achèvement de celle-ci.
  • La réponse à exec, l’état de sortie facultatif, EOF et la fermeture bilatérale marquent des étapes différentes, pas un résultat applicatif interchangeable.
  • Pour une opération à effet durable, un identifiant idempotent et une voie de consultation à distance permettent de résoudre l’incertitude après une coupure sans répéter aveuglément l’action.

Quatre questions derrière un seul voyant vert

L’utilisateur d’un outil distant demande simplement si l’action a réussi. Le protocole répond, lui, à plusieurs questions étroites : le canal est-il ouvert ? Le serveur a-t-il accepté la demande exec ? Le pair accorde-t-il davantage de capacité d’envoi ? Le processus a-t-il renvoyé un état de sortie ? Les deux extrémités ont-elles fermé leur canal ?

La distinction n’est pas académique. Une demande de lancement peut être acceptée avant un échec. Les données peuvent progresser alors que le programme ne les a pas encore interprétées. Un processus peut confier le travail à une file puis terminer. Enfin, la réponse définitive peut se perdre après que l’effet a déjà eu lieu.

Un modèle d’exploitation honnête conserve donc quatre états : admission de la demande, crédit de flux sur le canal, terminaison du processus et résultat durable de l’application. SSH rend visibles les trois premiers. Seul le programme exploité peut définir le dernier.

Ce que la fenêtre accorde réellement

La section 5.2 du RFC 4254 définit la fenêtre en octets. Elle fixe la quantité que l’autre partie peut envoyer avant de devoir attendre. SSH_MSG_CHANNEL_WINDOW_ADJUST désigne le canal destinataire et le nombre d’octets à ajouter. Les données ordinaires et étendues, dont la sortie d’erreur, consomment la même réserve.

Il s’agit d’un contrat de régulation de flux. Ses champs parlent de canal et de quantité ; ils ne transportent ni identifiant de commande, ni état d’application, ni preuve de persistance. Le texte n’impose pas non plus l’événement interne qui doit précéder l’augmentation de la fenêtre. Les choix de tampon et d’ordonnancement restent ceux de l’implémentation.

On peut donc conclure que le pair accepte davantage de trafic de canal. On ne peut pas en déduire qu’un octet précis a traversé la bibliothèque SSH, le système d’exploitation, le processus invoqué et le service aval. La fenêtre protège une capacité convenue ; elle ne tient pas le registre des effets.

Accepter le lancement n’est pas terminer

Les demandes propres au canal ont leur mécanisme de réponse. Si want reply vaut vrai, le destinataire renvoie un succès, un échec ou une continuation spécifique. La demande exec prie le serveur de commencer l’exécution de la commande, et le RFC recommande de réclamer puis de vérifier la réponse.

Cette réponse sépare utilement une demande admise d’une demande rejetée. Mais le cycle de vie de la commande vient seulement de commencer. Le succès du canal ne contient ni le code de sortie ultérieur, ni l’objet durable que l’application pourrait créer.

Les bibliothèques qui nomment ce moment « success » sans exposer sa couche favorisent la confusion. Les journaux devraient indiquer ce qui est attesté et relier l’événement à la session, au canal et à l’empreinte de la commande.

Un état de sortie plus probant, mais limité

Le RFC 4254 prévoit exit-status après la terminaison de la commande distante. Son envoi est recommandé, pas obligatoire. Il n’est pas lui-même acquitté et le client peut l’ignorer. La valeur zéro signifie « habituellement » une terminaison réussie.

Pour un programme synchrone qui ne sort à zéro qu’après réalisation de son contrat, ce signal peut suffire. Il est nettement plus proche du résultat que le crédit d’octets.

Mais un script peut sortir à zéro après avoir seulement placé une tâche dans une file. Un gestionnaire peut accepter un redémarrage avant le retour en bonne santé. Un outil de déploiement peut modifier le plan de contrôle tandis que les instances convergent encore. SSH transporte fidèlement le résultat du processus ; il ne crée pas le sens métier du programme.

La fermeture ne résout pas l’inconnu

EOF annonce qu’une partie n’enverra plus de données. Il ne reçoit pas de réponse explicite et n’interrompt pas l’autre direction. Une partie peut fermer sans avoir envoyé ni reçu EOF. Elle considère le canal fermé après avoir envoyé et reçu SSH_MSG_CHANNEL_CLOSE. La remise des données antérieures à leur destination n’est recommandée que si elle est possible.

Cette mécanique termine proprement l’état de communication. Elle ne garantit pas que chaque octet antérieur a produit un effet. Inversement, l’absence du dernier message ne prouve pas l’absence d’effet. Une coupure peut survenir après la validation distante mais avant que le client n’en reçoive la trace.

Marquer cet inconnu comme un échec certain puis relancer une opération non idempotente fabrique le doublon que le protocole ne pouvait empêcher.

Une preuve authentifiée garde son périmètre

Le RFC 4251 sépare transport, authentification de l’utilisateur et connexion. Le RFC 4253 assure chiffrement, authentification du serveur et intégrité ; le RFC 4252 authentifie l’utilisateur côté client ; la connexion multiplexe ensuite les canaux logiques.

Ces garanties répondent à l’identité du pair, à celle de l’utilisateur et à la protection des données en transit. Elles ne disent pas qu’une migration a été validée, qu’un paquet a atteint l’état souhaité ou qu’une API appelée par le programme a fini son travail. Une authentification robuste rend la preuve attribuable, sans élargir ce qu’elle prouve.

Donner à l’opération une identité persistante

Une action coûteuse ou irréversible devrait porter un identifiant survivant à la session SSH. Le système distant peut lui associer le principal authentifié, la cible, l’empreinte de la requête, l’heure d’admission, l’état courant, le résultat final et l’identifiant de l’objet créé. Le client doit pouvoir consulter ce dossier après reconnexion.

Aucune extension SSH n’est indispensable : un contrat de ligne de commande peut accepter une clé d’idempotence, rendre un identifiant d’opération et permettre sa consultation. Pour une lecture ou une commande démontrée idempotente, la sortie et le code de fin suffiront souvent. La discipline supplémentaire devient essentielle lorsqu’une répétition pourrait créer deux ressources, faire tourner deux fois un secret ou interrompre de nouveau une flotte.

Le principe est de nommer les preuves sans les gonfler : ajustement de fenêtre pour le crédit d’octets, succès de requête pour l’admission, état de sortie pour le processus, fermeture pour le canal. Le résultat métier appartient à l’opération métier.

Sources