Resumen

  • SSH_MSG_CHANNEL_WINDOW_ADJUST concede permiso para enviar más bytes por un canal SSH; no acredita que una orden los haya procesado ni que haya terminado.
  • La respuesta a exec, el estado de salida opcional, EOF y el cierre bilateral describen momentos diferentes y no sustituyen un resultado persistente de la aplicación.
  • Las operaciones con efectos importantes necesitan una identidad idempotente y una consulta posterior que sobrevivan a la sesión SSH, para no reintentar a ciegas después de un corte.

Cuatro estados bajo una sola etiqueta

Quien usa una herramienta de ejecución remota quiere una respuesta breve: ¿funcionó? El protocolo contesta preguntas más delimitadas. ¿Se abrió el canal? ¿Aceptó el servidor la petición exec? ¿Puede el emisor introducir más datos? ¿Informó el proceso de un estado de salida? ¿Cerraron ambos extremos el canal?

Separarlas tiene consecuencias prácticas. Una petición puede ser admitida y fracasar después. Los datos pueden avanzar mientras el programa sigue esperando. Un proceso puede delegar el trabajo en una cola antes de salir. La conexión puede perderse justo después de que el efecto se consolide y antes de que llegue su prueba.

Por eso el modelo debería conservar cuatro estados: admisión de la petición, crédito de flujo del canal, terminación del proceso y resultado duradero de la aplicación. SSH permite observar los tres primeros. El programa remoto define el cuarto.

Qué concede la ventana

La sección 5.2 del RFC 4254 define la ventana en bytes: es la cantidad que la otra parte puede enviar antes de esperar un ajuste. SSH_MSG_CHANNEL_WINDOW_ADJUST indica el canal receptor y los bytes que se agregan. Los datos ordinarios y los extendidos, como el error estándar, consumen la misma reserva.

Es un contrato de control de flujo. Sus campos expresan canal y cantidad, no identidad de orden, estado de aplicación, persistencia ni resumen del resultado. La norma tampoco fija qué acontecimiento interno debe provocar un nuevo crédito; el diseño de búferes y planificación pertenece a cada implementación.

El ajuste permite inferir que el par acepta más tráfico del canal. No permite afirmar que un byte haya cruzado la biblioteca SSH, el sistema operativo, el proceso invocado y cualquier servicio posterior. La ventana limita capacidad acordada; no lleva la contabilidad de los efectos.

Aceptar el inicio no es acabar

Las peticiones específicas del canal tienen otro mecanismo. Con want reply activado, el receptor responde con éxito, fallo o una continuación propia de la petición. exec solicita al servidor que inicie la orden indicada, y el RFC recomienda pedir y comprobar la respuesta.

La respuesta distingue correctamente la admisión del rechazo. Aun así, la vida de la orden apenas empieza. El éxito de la petición no contiene el código de salida futuro ni el identificador persistente que pueda crear la aplicación.

Cuando una biblioteca llama “success” a ese evento sin exponer la capa, el nombre suena definitivo. Los registros de operación deben decir qué acredita el evento y enlazarlo con la sesión, el canal y la huella de la orden.

El estado de salida es más fuerte, pero limitado

El RFC 4254 define exit-status para después de que termine la orden remota. Enviarlo está recomendado, no exigido; no recibe confirmación y el cliente puede ignorarlo. Un cero significa “normalmente” terminación satisfactoria.

Para un programa síncrono cuyo contrato establece que solo sale con cero tras completar la acción, puede ser una conclusión suficiente. Está mucho más cerca del resultado que el presupuesto de bytes.

Pero un envoltorio puede devolver cero después de poner trabajo en una cola. Un gestor puede aceptar un reinicio antes de recuperar la salud. Un despliegue puede modificar el plano de control mientras las réplicas siguen convergiendo. SSH transporta el resultado del proceso; no inventa la semántica del programa.

El cierre termina el canal, no la incertidumbre

EOF comunica que una parte no enviará más datos, no tiene respuesta explícita y no cierra el sentido opuesto. Cualquiera puede enviar close sin un EOF previo. Cada extremo considera cerrado el canal cuando ha enviado y recibido close. La entrega de los datos anteriores al destino real solo se recomienda cuando sea posible.

Es un final ordenado del recurso de comunicación, no una garantía de que todo byte produjo un efecto. Tampoco la ausencia del último mensaje prueba que nada ocurrió. Un corte puede dejar el cambio consolidado en el servidor y al cliente sin saberlo.

Transformar ese desconocimiento en fracaso seguro y repetir una acción no idempotente crea el duplicado que el canal no está diseñado para resolver.

La seguridad conserva sus límites

El RFC 4251 divide SSH en transporte, autenticación de usuario y conexión. El RFC 4253 aporta cifrado, autenticación del servidor e integridad; el RFC 4252 autentica al usuario cliente; después, la conexión multiplexa canales lógicos.

Estas garantías responden quién es el servidor, qué usuario fue autenticado y si los datos viajaron protegidos. No responden si una migración hizo commit, si un paquete alcanzó el estado esperado o si una API delegada acabó. La autenticación sólida atribuye la evidencia; no amplía su significado.

Una operación que sobreviva a la sesión

Una acción irreversible o cara debería tener un identificador que no muera con SSH. El sistema remoto puede asociarle principal autenticado, destino, huella de la solicitud, hora de admisión, estado actual, resultado final y objeto creado. El cliente necesita consultar ese registro después de reconectar.

No hace falta alterar SSH. Una interfaz de línea de órdenes puede aceptar una clave de idempotencia, devolver un ID de operación y permitir su consulta. Para una lectura o una acción demostrablemente idempotente, salida y código final suelen bastar. La protección adicional corresponde a acciones cuya repetición podría crear dos recursos, rotar dos veces una credencial o interrumpir de nuevo una flota.

La regla es llamar a cada prueba por su nombre: ajuste de ventana es crédito de bytes; éxito de petición es admisión; estado de salida es evidencia del proceso; close es final de canal. La culminación de negocio debe proceder de la operación de negocio.

Fuentes