Se si omette --password, il server chiede la password di login USSH all'avvio.
All'avvio interattivo, il server chiede se deve installarsi come servizio systemd. Rispondere n per eseguirlo normalmente. Usare --no-systemd-prompt per saltare quella domanda.
Il client richiede la password in modo interattivo, come SSH.
Il client memorizza la prima chiave pubblica X25519 del server vista in ~/.ussh_known_hosts.json.
Se in seguito quella chiave cambia, il client si interrompe con un errore di mancata corrispondenza TOFU invece di fidarsi silenziosamente della nuova chiave.
Se si è ruotata intenzionalmente la chiave host del server, eseguire il client con --regen-key per consentire la sostituzione della chiave TOFU memorizzata dopo conferma interattiva.
Sotto USSH, USTPS utilizza linee di controllo ASCII leggibili come ACK: 10 MAC:<tag>, NACK: 42 MAC:<tag>, HELLO: ..., CLOSE:, più frame DATA binari UPACK (UPAK).
ACK e NACK rimangono in chiaro per facilità di debug, ma sono autenticati con un tag HMAC per sessione per prevenire attacchi di controllo ACK/NACK falsificati.
USSH eredita il limite di carico utile del trasporto USTPS di 900 byte per payload DATA UPACK.
USSH non definisce un secondo livello di frammentazione al di sotto di USTPS.
Il comportamento a livello di trasporto per MTU, PMTU, nonce, gestione dei duplicati e gestione dei pacchetti obsoleti è ereditato da USTPS.
La migrazione automatica della rete/percorso è stata rimossa.
Se il client cambia rete e il suo IP:porta sorgente cambia, si prevede che la sessione USSH corrente si chiuda e l'utente si riconnetta correttamente.
Handshake del trasporto
USSH eredita lo stesso handshake con token di ripetizione di USTPS come USTP-Secure.
Il server prima sfida il client con un token di ripetizione e metadati di sessione.
Il client deve restituire quel token prima che la sessione USSH crittografata venga accettata.
Lo stesso handshake negozia anche il cifrario AEAD finale e se USTPS Congestion è on o off.
Il token di ripetizione è solo una prova di raggiungibilità prima della creazione della sessione.
Non è la chiave di sessione, non è un nonce del pacchetto e non è un sostituto della successiva chiave di sessione AEAD derivata.
L'implementazione della migrazione è stata rimossa perché causava problemi pratici di affidabilità e sicurezza:
inondazioni di migrazione ripetute quando NAT o reti mobili cambiavano percorso rapidamente
sessioni che sembravano riprese ma smettevano di consegnare dati del terminale
lunghi periodi di silenzio prima che il client notasse che il percorso era morto
ambiguità tra un client in roaming reale e pacchetti falsificati che rivendicavano una sessione esistente
stato di recupero che poteva lasciare il terminale bloccato invece di riconnettersi correttamente
Il comportamento attuale è intenzionalmente più semplice: validare il client sull'IP:porta corrente, associare la sessione a quell'endpoint e riconnettersi se l'endpoint cambia.
USSH eredita il USTPS Congestion opzionale dal trasporto.
Lato server: --congestion-control auto|on|off
Lato client: --congestion-control on|off
Con server auto, USSH segue la richiesta del client. Con server on o off, il server impone la modalità finale.
USTP-Secure stesso rimane non ordinato.
USSH non trasforma il trasporto in un canale ordinato simile a TCP.
USSH riassembla solo il flusso di byte logico stdout prima di scrivere sul terminale.
USSH può anche mantenere l'ordinamento a livello di applicazione per blocchi di input/output della shell dove un PTY si aspetta un comportamento coerente del flusso di byte.
Questo riassemblaggio esiste perché l'output di una shell interattiva è un flusso di byte continuo e il rendering dei byte del terminale nell'ordine di arrivo grezzo può corrompere output grandi come ls, find o log del compilatore.
Ciò significa che USTP-Secure evita comunque il blocco testa di linea a livello di trasporto, mentre USSH ripristina solo l'ordine a livello di applicazione necessario per il rendering del terminale.
I payload sono crittografati per pacchetto con AEAD.
Non viene utilizzato alcun PSK statico.
Ogni client riceve una chiave di sessione AEAD effimera separata tramite X25519.
La password viene utilizzata per l'autenticazione USSH dopo che la sessione sicura è stata stabilita.
Il server avvia una shell reale con supporto PTY sulla macchina che esegue ussh_server.py.
Il client invia byte stdin e visualizza byte stdout.
Il server supporta più client, con una shell/sessione per client.
Se --cipher è impostato sul server, il server utilizza quel cifrario esatto.
Se --cipher è omesso o impostato su auto, il server utilizza il cifrario richiesto dal client.
I client rifiutano la negoziazione del cifrario inaspettata.
TOFU (Trust On First Use) è abilitato sul client per rilevare cambiamenti imprevisti della chiave del server dopo la prima connessione.
Il server mantiene una chiave host X25519 persistente in ~/.ussh_host_key per impostazione predefinita in modo che TOFU rimanga stabile tra riconnessioni e riavvii.
Un riavvio normale del server non cambia la chiave host.
Usare --regen-key sul server solo quando si intende ruotare intenzionalmente quella chiave host.
Le voci TOFU sono memorizzate per <peer-ip-or-domain>:<peer-port>, quindi un server diverso a un indirizzo/porta diverso viene trattato come un'identità host diversa.
x1colegal/ussh
