Si --password est omis, le serveur demande le mot de passe de connexion USSH au démarrage.
Au démarrage interactif, le serveur demande s'il doit s'installer comme service systemd. Répondez n pour l'exécuter normalement. Utilisez --no-systemd-prompt pour ignorer cette question.
Le client demande le mot de passe de manière interactive, comme SSH.
Le client stocke la première clé publique X25519 du serveur vue dans ~/.ussh_known_hosts.json.
Si cette clé change ultérieurement, le client abandonne avec une erreur de non-concordance TOFU au lieu de faire silencieusement confiance à la nouvelle clé.
Si vous avez intentionnellement fait pivoter la clé d'hôte du serveur, exécutez le client avec --regen-key pour permettre le remplacement de la clé TOFU stockée après confirmation interactive.
USSH prend également en charge un mode DATA en clair optionnel avec intégrité HMAC par paquet :
Côté serveur : --cleartext auto|on|off
Côté client : --cleartext on|off
Avec le serveur en auto, USSH suit la demande du client.
Avec le serveur en on ou off, le serveur impose le mode en clair final.
Lorsque --cleartext on est utilisé, USSH affiche un avertissement indiquant que le mode en clair est dangereux sur l'Internet réel et n'est recommandé que dans des environnements contrôlés comme un réseau local.
Sous USSH, USTPS utilise des lignes de contrôle ASCII lisibles comme ACK: 10 MAC:<tag>, NACK: 42 MAC:<tag>, HELLO: ..., CLOSE:, plus des trames DATA binaires UPACK (UPAK).
Établissement de liaison du transport
USSH hérite du même établissement de liaison avec jeton de nouvelle tentative USTPS qu'USTP-Secure.
Le serveur défie d'abord le client avec un jeton de nouvelle tentative et des métadonnées de session.
Le client doit renvoyer ce jeton avant que la session USSH chiffrée ne soit acceptée.
Le même établissement de liaison négocie également le chiffrement AEAD final et si USTPS Congestion est on ou off.
Le même établissement de liaison négocie également si DATA utilise le chiffrement AEAD ou le mode en clair plus HMAC.
Le jeton de nouvelle tentative n'est qu'une preuve d'accessibilité avant la création de la session.
Ce n'est pas la clé de session, ni un nonce de paquet, ni un remplacement de la clé de session AEAD dérivée ultérieurement.
ACK et NACK restent en clair pour faciliter le débogage, mais ils sont authentifiés avec une balise HMAC par session pour empêcher les attaques de contrôle ACK/NACK forgées.
En mode normal, les charges utiles DATA utilisent le chiffrement AEAD.
En mode en clair, les charges utiles DATA ne sont pas chiffrées, mais elles portent toujours un HMAC afin qu'un tiers ne puisse pas les modifier sans être détecté.
USSH hérite du plafond de charge utile du transport USTPS de 900 octets par charge utile DATA UPACK.
USSH ne définit pas de deuxième couche de fragmentation sous USTPS.
Le MTU au niveau transport, le PMTU, le comportement des nonces, la gestion des doublons et la gestion des paquets obsolètes sont hérités d'USTPS.
La migration automatique de réseau/chemin a été supprimée.
Si le client change de réseau et que son IP:port source change, la session USSH actuelle doit se fermer et l'utilisateur doit se reconnecter proprement.
L'implémentation de la migration a été supprimée car elle causait des problèmes pratiques de fiabilité et de sécurité :
des inondations de migration répétées lorsque les réseaux NAT ou mobiles changeaient de chemin rapidement
des sessions qui semblaient rétablies mais cessaient de délivrer les données du terminal
de longues périodes de silence avant que le client ne détecte que le chemin était mort
une ambiguïté entre un vrai client itinérant et des paquets usurpés revendiquant une session existante
un état de récupération qui pouvait laisser le terminal bloqué au lieu de se reconnecter proprement
Le comportement actuel est intentionnellement plus simple : valider le client sur l'IP:port actuel, lier la session à ce point de terminaison, et se reconnecter si le point de terminaison change.
USSH hérite de la USTPS Congestion optionnelle du transport.
Côté serveur : --congestion-control auto|on|off
Côté client : --congestion-control on|off
Avec le serveur en auto, USSH suit la demande du client. Avec le serveur en on ou off, le serveur impose le mode final.
USTP-Secure lui-même reste non ordonné.
USSH ne transforme pas le transport en canal ordonné de type TCP.
USSH ne réassemble que le flux d'octets logique stdout avant de l'écrire dans le terminal.
USSH peut également maintenir un ordonnancement au niveau application pour les morceaux d'entrée/sortie du shell là où un PTY attend un comportement cohérent de flux d'octets.
Cette réassemblage existe parce que la sortie d'un shell interactif est un flux d'octets continu, et rendre les octets du terminal dans l'ordre brut d'arrivée peut corrompre de grandes sorties comme ls, find ou les journaux du compilateur.
Cela signifie qu'USTP-Secure évite toujours le blocage de tête de ligne au niveau transport, tandis qu'USSH ne restaure que l'ordre au niveau application requis pour le rendu du terminal.
Les charges utiles sont chiffrées par paquet avec AEAD.
Aucun PSK statique n'est utilisé.
Chaque client reçoit une clé de session AEAD éphémère distincte via X25519.
Le mot de passe est utilisé pour l'authentification USSH après l'établissement de la session sécurisée.
Le serveur lance un shell réel adossé à un PTY sur la machine exécutant ussh_server.py.
Le client envoie les octets de stdin et rend les octets de stdout.
Le serveur prend en charge plusieurs clients, avec un shell/session par client.
Si --cipher est défini sur le serveur, le serveur utilise exactement ce chiffrement.
Si --cipher est omis ou défini sur auto, le serveur utilise le chiffrement demandé par le client.
Les clients rejettent toute négociation de chiffrement inattendue.
TOFU (Trust On First Use) est activé sur le client pour détecter les changements inattendus de clé serveur après la première connexion.
Le serveur conserve une clé d'hôte X25519 persistante dans ~/.ussh_host_key par défaut afin que TOFU reste stable entre les reconnexions et les redémarrages.
Un redémarrage normal du serveur ne change pas la clé d'hôte.
Utilisez --regen-key sur le serveur uniquement lorsque vous souhaitez intentionnellement faire pivoter cette clé d'hôte.
Les entrées TOFU sont stockées par <peer-ip-or-domain>:<peer-port>, donc un serveur différent à une adresse/port différent est traité comme une identité d'hôte différente.
x1colegal/ussh
