Si se omite --password, el servidor solicita la contraseña de inicio de sesión de USSH al arrancar.
En el arranque interactivo, el servidor pregunta si debe instalarse como un servicio systemd. Responda n para ejecutarlo normalmente. Use --no-systemd-prompt para omitir esa pregunta.
El cliente solicita la contraseña de forma interactiva, como SSH.
El cliente almacena la primera clave pública X25519 del servidor vista en ~/.ussh_known_hosts.json.
Si esa clave cambia más adelante, el cliente aborta con un error de discrepancia TOFU en lugar de confiar silenciosamente en la nueva clave.
Si ha rotado intencionalmente la clave de host del servidor, ejecute el cliente con --regen-key para permitir reemplazar la clave TOFU almacenada tras una confirmación interactiva.
Internet-Drafts
Internet-Draft de USSH: https://datatracker.ietf.org/doc/draft-x1co-ussh/
Notas
El transporte es USTP-Secure sobre UDP.
USSH también admite un modo DATA en claro opcional con integridad HMAC por paquete:
Lado del servidor: --cleartext auto|on|off
Lado del cliente: --cleartext on|off
Con el servidor en auto, USSH sigue la solicitud del cliente.
Con el servidor en on u off, el servidor fuerza el modo en claro final.
Cuando se usa --cleartext on, USSH muestra una advertencia de que el modo en claro es peligroso en Internet real y solo se recomienda en entornos controlados, como una red local.
Debajo de USSH, USTPS usa líneas de control ASCII legibles como ACK: 10 MAC:<tag>, NACK: 42 MAC:<tag>, HELLO: ..., CLOSE:, además de tramas DATA binarias UPACK (UPAK).
Protocolo de enlace de transporte
USSH hereda el mismo protocolo de enlace de token de reintento USTPS que USTP-Secure.
El servidor primero desafía al cliente con un token de reintento y metadatos de sesión.
El cliente debe devolver ese token antes de que se acepte la sesión USSH cifrada.
El mismo protocolo de enlace también negocia el cifrado AEAD final y si USTPS Congestion está on u off.
El mismo protocolo de enlace también negocia si DATA usa cifrado AEAD o texto en claro más HMAC.
El token de reintento es solo una prueba de alcanzabilidad antes de la creación de la sesión.
No es la clave de sesión, no es un nonce de paquete y no reemplaza la clave de sesión AEAD derivada posteriormente.
ACK y NACK permanecen en texto plano para facilitar la depuración, pero están autenticados con una etiqueta HMAC por sesión para prevenir ataques de control ACK/NACK falsificados.
En modo normal, las cargas útiles DATA usan cifrado AEAD.
En modo en claro, las cargas útiles DATA no están cifradas, pero aún llevan un HMAC para que un tercero no pueda modificarlas sin ser detectado.
USSH hereda el límite de carga útil del transporte USTPS de 900 bytes por carga útil DATA UPACK.
USSH no define una segunda capa de fragmentación por debajo de USTPS.
El MTU a nivel de transporte, PMTU, comportamiento de nonce, manejo de duplicados y manejo de paquetes obsoletos se heredan de USTPS.
La migración automática de red/ruta se ha eliminado.
Si el cliente cambia de red y su IP:puerto de origen cambia, se espera que la sesión USSH actual se cierre y el usuario deba reconectarse limpiamente.
La implementación de migración se eliminó porque causaba problemas prácticos de fiabilidad y seguridad:
inundaciones de migración repetidas cuando las redes NAT o móviles cambiaban de ruta rápidamente
sesiones que parecían recuperadas pero dejaban de entregar datos de terminal
largos períodos de silencio antes de que el cliente notara que la ruta estaba muerta
ambigüedad entre un cliente real en itinerancia y paquetes falsificados que reclamaban una sesión existente
estado de recuperación que podía dejar la terminal bloqueada en lugar de reconectarse limpiamente
El comportamiento actual es intencionalmente más simple: validar al cliente en la IP:puerto actual, vincular la sesión a ese endpoint y reconectarse si el endpoint cambia.
USSH hereda el USTPS Congestion opcional del transporte.
Lado del servidor: --congestion-control auto|on|off
Lado del cliente: --congestion-control on|off
Con el servidor en auto, USSH sigue la solicitud del cliente. Con el servidor en on u off, el servidor fuerza el modo final.
USTP-Secure en sí mismo permanece sin orden.
USSH no convierte el transporte en un canal ordenado tipo TCP.
USSH solo reensambla el flujo de bytes lógico de stdout antes de escribirlo en la terminal.
USSH también puede mantener el orden a nivel de aplicación para los fragmentos de entrada/salida del shell donde una PTY espera un comportamiento coherente de flujo de bytes.
Ese reensamblaje existe porque la salida de un shell interactivo es un flujo continuo de bytes, y renderizar los bytes de la terminal en el orden bruto de llegada puede corromper salidas grandes como ls, find o registros de compilador.
Esto significa que USTP-Secure aún evita el bloqueo de cabeza de línea (Head-of-Line) a nivel de transporte, mientras que USSH restaura solo el orden a nivel de aplicación requerido para el renderizado de la terminal.
Las cargas útiles se cifran por paquete con AEAD.
No se usa ningún PSK estático.
Cada cliente recibe una clave de sesión AEAD efímera separada a través de X25519.
La contraseña se usa para la autenticación de USSH después de que se establece la sesión segura.
El servidor lanza un shell real respaldado por PTY en la máquina que ejecuta ussh_server.py.
El cliente envía bytes de stdin y renderiza bytes de stdout.
El servidor admite múltiples clientes, con un shell/sesión por cliente.
Si --cipher está configurado en el servidor, el servidor usa ese cifrado exacto.
Si --cipher se omite o se establece en auto, el servidor usa el cifrado solicitado por el cliente.
Los clientes rechazan una negociación de cifrado inesperada.
TOFU (Trust On First Use) está habilitado en el cliente para detectar cambios inesperados de clave del servidor después de la primera conexión.
El servidor mantiene una clave de host X25519 persistente en ~/.ussh_host_key de forma predeterminada para que TOFU permanezca estable entre reconexiones y reinicios.
Un reinicio normal del servidor no cambia la clave de host.
Use --regen-key en el servidor solo cuando desee rotar intencionalmente esa clave de host.
Las entradas TOFU se almacenan por <peer-ip-or-domain>:<peer-port>, por lo que un servidor diferente en una dirección/puerto diferente se trata como una identidad de host diferente.
x1colegal/ussh
