Se --password viene omesso, il server richiede la password di accesso USSH all'avvio.
All'avvio interattivo, il server chiede se deve installarsi come servizio systemd. Rispondi n per eseguirlo normalmente. Usa --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 quella chiave cambia in seguito, il client si interrompe con un errore di mancata corrispondenza TOFU invece di fidarsi silenziosamente della nuova chiave.
Se hai ruotato intenzionalmente la chiave host del server, esegui il client con --regen-key per consentire la sostituzione della chiave TOFU memorizzata dopo conferma interattiva.
USSH supporta anche una modalità DATA in chiaro opzionale con integrità HMAC per pacchetto:
Lato server: --cleartext auto|on|off
Lato client: --cleartext on|off
Con server auto, USSH segue la richiesta del client.
Con server on o off, il server impone la modalità in chiaro finale.
Quando si usa --cleartext on, USSH stampa un avviso che il testo in chiaro è pericoloso su Internet reale ed è consigliato solo in ambienti controllati come una rete locale.
Sotto USSH, USTPS usa righe di controllo ASCII leggibili come ACK: 10 MAC:<tag>, NACK: 42 MAC:<tag>, HELLO: ..., CLOSE:, più frame DATA binari UPACK (UPAK).
Handshake di trasporto
USSH eredita lo stesso handshake con retry token USTPS di USTP-Secure.
Il server sfida prima il client con un retry token e metadati di sessione.
Il client deve rimandare indietro quel token prima che la sessione USSH crittografata venga accettata.
Lo stesso handshake negozia anche il cifrario AEAD finale e se la Congestione USTPS è on o off.
Lo stesso handshake negozia anche se DATA usa crittografia AEAD o testo in chiaro più HMAC.
Il retry token è solo una prova di raggiungibilità prima della creazione della sessione.
Non è la chiave di sessione, non è un nonce di pacchetto e non sostituisce la successiva chiave di sessione AEAD derivata.
ACK e NACK restano in chiaro per la debuggabilità, ma sono autenticati con un tag HMAC per sessione per prevenire attacchi di controllo ACK/NACK falsificati.
In modalità normale, i payload DATA usano crittografia AEAD.
In modalità in chiaro, i payload DATA non sono crittografati, ma portano comunque un HMAC così una terza parte non può modificarli senza essere rilevata.
USSH eredita il limite di payload del trasporto USTPS di 900 byte per payload DATA UPACK.
USSH non definisce un secondo livello di frammentazione sotto USTPS.
MTU a livello di trasporto, PMTU, comportamento dei nonce, gestione dei duplicati e gestione dei pacchetti obsoleti sono ereditati da USTPS.
La migrazione automatica di rete/percorso è stata rimossa.
Se il client cambia rete e il suo IP:porta di origine cambia, ci si aspetta che la sessione USSH corrente si chiuda e l'utente debba riconnettersi in modo pulito.
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 ripristinate 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 reale in roaming e pacchetti spoofati che rivendicavano una sessione esistente
stato di ripristino che poteva lasciare il terminale bloccato invece di riconnettersi in modo pulito
Il comportamento attuale è intenzionalmente più semplice: valida il client sull'IP:porta corrente, vincola la sessione a quell'endpoint e riconnettiti se l'endpoint cambia.
USSH eredita la Congestione USTPS 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 scriverlo sul terminale.
USSH può anche mantenere l'ordinamento a livello applicativo per i blocchi di input/output della shell dove una PTY si aspetta un comportamento coerente di flusso di byte.
Quel riassemblaggio esiste perché l'output di una shell interattiva è un flusso di byte continuo, e renderizzare i byte del terminale nell'ordine grezzo di arrivo può corrompere output di grandi dimensioni come ls, find o log del compilatore.
Questo significa che USTP-Secure evita comunque il blocco Head-of-Line a livello di trasporto, mentre USSH ripristina solo l'ordine a livello applicativo richiesto per il rendering del terminale.
I payload sono crittografati per pacchetto con AEAD.
Non viene usato alcun PSK statico.
Ogni client riceve una chiave di sessione AEAD effimera separata tramite X25519.
La password viene usata per l'autenticazione USSH dopo che la sessione sicura è stata stabilita.
Il server avvia una shell reale supportata da PTY sulla macchina che esegue ussh_server.py.
Il client invia i byte di stdin e renderizza i byte di stdout.
Il server supporta più client, con una shell/sessione per client.
Se --cipher è impostato sul server, il server usa esattamente quel cifrario.
Se --cipher viene omesso o impostato su auto, il server usa il cifrario richiesto dal client.
I client rifiutano negoziazioni di cifrario inattese.
TOFU (Trust On First Use) è abilitato sul client per rilevare cambiamenti inattesi della chiave del server dopo la prima connessione.
Il server mantiene una chiave host X25519 persistente in ~/.ussh_host_key per impostazione predefinita così TOFU rimane stabile tra riconnessioni e riavvii.
Un normale riavvio del server non cambia la chiave host.
Usa --regen-key sul server solo quando vuoi intenzionalmente ruotare 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
