Wenn --password weggelassen wird, fragt der Server beim Start nach dem USSH-Login-Passwort.
Beim interaktiven Start fragt der Server, ob er sich selbst als systemd-Dienst installieren soll. Antworten Sie mit n, um ihn normal auszuführen. Verwenden Sie --no-systemd-prompt, um diese Frage zu überspringen.
Der Client fragt das Passwort interaktiv ab, ähnlich wie SSH.
Der Client speichert den ersten gesehenen X25519-Server-öffentlichen Schlüssel in ~/.ussh_known_hosts.json.
Wenn sich dieser Schlüssel später ändert, bricht der Client mit einem TOFU-Fehler ab, anstatt dem neuen Schlüssel stillschweigend zu vertrauen.
Wenn Sie den Server-Hostschlüssel absichtlich rotiert haben, führen Sie den Client mit --regen-key aus, um nach interaktiver Bestätigung das Ersetzen des gespeicherten TOFU-Schlüssels zu erlauben.
USSH unterstützt außerdem einen optionalen Klartext-DATA-Modus mit HMAC-Integrität pro Paket:
Serverseite: --cleartext auto|on|off
Clientseite: --cleartext on|off
Bei Server auto folgt USSH der Client-Anfrage.
Bei Server on oder off erzwingt der Server den endgültigen Klartextmodus.
Wenn --cleartext on verwendet wird, gibt USSH eine Warnung aus, dass Klartext im echten Internet gefährlich ist und nur in kontrollierten Umgebungen wie einem lokalen Netzwerk empfohlen wird.
Unterhalb von USSH verwendet USTPS lesbare ASCII-Steuerzeilen wie ACK: 10 MAC:<tag>, NACK: 42 MAC:<tag>, HELLO: ..., CLOSE: sowie binäre UPACK (UPAK) DATA-Frames.
Transport-Handshake
USSH übernimmt denselben USTPS-Retry-Token-Handshake wie USTP-Secure.
Der Server fordert den Client zunächst mit einem Retry-Token und Sitzungsmetadaten heraus.
Der Client muss dieses Token zurücksenden, bevor die verschlüsselte USSH-Sitzung akzeptiert wird.
Derselbe Handshake handelt auch die endgültige AEAD-Chiffre aus und ob USTPS Congestionon oder off ist.
Derselbe Handshake handelt auch aus, ob DATA AEAD-Verschlüsselung oder Klartext plus HMAC verwendet.
Das Retry-Token ist nur ein Erreichbarkeitsnachweis vor der Sitzungserstellung.
Es ist nicht der Sitzungsschlüssel, kein Paket-Nonce und kein Ersatz für den später abgeleiteten AEAD-Sitzungsschlüssel.
ACK und NACK bleiben zur Debugbarkeit im Klartext, werden aber mit einem HMAC-Tag pro Sitzung authentifiziert, um gefälschte ACK/NACK-Steuerungsangriffe zu verhindern.
Im normalen Modus verwenden DATA-Nutzlasten AEAD-Verschlüsselung.
Im Klartextmodus werden DATA-Nutzlasten nicht verschlüsselt, tragen aber dennoch einen HMAC, sodass ein Dritter sie nicht unbemerkt verändern kann.
USSH übernimmt die USTPS-Transport-Nutzlastobergrenze von 900 Bytes pro UPACK DATA-Nutzlast.
USSH definiert keine zweite Fragmentierungsebene unterhalb von USTPS.
MTU auf Transportebene, PMTU, Nonce-Verhalten, Duplikatbehandlung und Behandlung veralteter Pakete werden von USTPS übernommen.
Die automatische Netzwerk-/Pfadmigration wurde entfernt.
Wenn der Client das Netzwerk wechselt und sich seine Quell-IP:port ändert, wird erwartet, dass die aktuelle USSH-Sitzung geschlossen wird und der Benutzer sich sauber neu verbindet.
Die Migrationsimplementierung wurde entfernt, weil sie praktische Zuverlässigkeits- und Sicherheitsprobleme verursachte:
wiederholte Migrationsfluten, wenn NAT- oder Mobilfunknetze Pfade schnell wechselten
Sitzungen, die als wiederhergestellt erschienen, aber keine Terminaldaten mehr lieferten
lange stille Phasen, bevor der Client bemerkte, dass der Pfad tot war
Mehrdeutigkeit zwischen einem echten Roaming-Client und gespooften Paketen, die eine bestehende Sitzung beanspruchten
Wiederherstellungszustand, der das Terminal hängen lassen konnte, anstatt sauber neu zu verbinden
Das aktuelle Verhalten ist bewusst einfacher: Validieren Sie den Client auf der aktuellen IP:port, binden Sie die Sitzung an diesen Endpunkt und verbinden Sie sich neu, wenn sich der Endpunkt ändert.
USSH übernimmt die optionale USTPS Congestion vom Transport.
Serverseite: --congestion-control auto|on|off
Clientseite: --congestion-control on|off
Bei Server auto folgt USSH der Client-Anfrage. Bei Server on oder off erzwingt der Server den endgültigen Modus.
USTP-Secure selbst bleibt ungeordnet.
USSH verwandelt den Transport nicht in einen geordneten TCP-ähnlichen Kanal.
USSH setzt nur den logischen stdout-Bytestrom vor dem Schreiben auf das Terminal wieder zusammen.
USSH kann auch die Reihenfolge auf Anwendungsebene für Shell-Eingabe-/Ausgabeblöcke beibehalten, wo eine PTY ein kohärentes Bytestrom-Verhalten erwartet.
Diese Wiederzusammenstellung existiert, weil die Ausgabe einer interaktiven Shell ein kontinuierlicher Bytestrom ist und das Rendern von Terminalbytes in reiner Ankunftsreihenfolge große Ausgaben wie ls, find oder Compiler-Logs beschädigen kann.
Das bedeutet, dass USTP-Secure weiterhin Head-of-Line-Blocking auf Transportebene vermeidet, während USSH nur die für das Terminal-Rendering erforderliche Reihenfolge auf Anwendungsebene wiederherstellt.
Nutzlasten werden pro Paket mit AEAD verschlüsselt.
Es wird kein statisches PSK verwendet.
Jeder Client erhält über X25519 einen separaten ephemeren AEAD-Sitzungsschlüssel.
Das Passwort wird für die USSH-Authentifizierung verwendet, nachdem die sichere Sitzung aufgebaut wurde.
Der Server startet eine echte PTY-gestützte Shell auf dem Rechner, auf dem ussh_server.py läuft.
Der Client sendet stdin-Bytes und rendert stdout-Bytes.
Der Server unterstützt mehrere Clients, mit einer Shell/Sitzung pro Client.
Wenn --cipher auf dem Server gesetzt ist, verwendet der Server genau diese Chiffre.
Wenn --cipher weggelassen oder auf auto gesetzt ist, verwendet der Server die vom Client angeforderte Chiffre.
Clients lehnen unerwartete Chiffre-Aushandlungen ab.
TOFU (Trust On First Use) ist auf dem Client aktiviert, um unerwartete Server-Schlüsseländerungen nach der ersten Verbindung zu erkennen.
Der Server speichert standardmäßig einen persistenten X25519-Hostschlüssel in ~/.ussh_host_key, sodass TOFU über Wiederverbindungen und Neustarts hinweg stabil bleibt.
Ein normaler Server-Neustart ändert den Hostschlüssel nicht.
Verwenden Sie --regen-key auf dem Server nur, wenn Sie diesen Hostschlüssel absichtlich rotieren möchten.
TOFU-Einträge werden pro <peer-ip-or-domain>:<peer-port> gespeichert, sodass ein anderer Server unter einer anderen Adresse/Port als andere Host-Identität behandelt wird.
x1colegal/ussh
