USSH

USSH ist ein Shell-Protokoll und ein Client/Server-Paar, das auf USTP-Secure aufbaut.

Es ist kein TCP-Tunnel und kapselt SSH nicht in TCP.

Status: Beta

Lizenz: MIT

AEAD-Chiffrenamen

• chacha20 = CHACHA20_POLY1305
• aes-256-gcm = AES_256_GCM
• aes-128-gcm = AES_128_GCM
• Standard-AEAD-Chiffre: chacha20

Standard-Port

• 5322

Server

python3 ussh_server.py \
  --peer-ip <CLIENT_IP_OR_DOMAIN> \
  --peer-port 0 \
  --bind-ip 0.0.0.0 \
  --bind-port 5322 \
  --cipher chacha20 \
  --congestion-control auto

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.

Client

python3 ussh_client.py \
  --peer-ip <SERVER_IP_OR_DOMAIN> \
  --peer-port 5322 \
  --bind-ip 0.0.0.0 \
  --bind-port 0 \
  --cipher chacha20 \
  --congestion-control off \
  --cleartext off

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.

Internet-Drafts

• USSH Internet-Draft: https://datatracker.ietf.org/doc/draft-x1co-ussh/

Hinweise

• Der Transport ist USTP-Secure über UDP.
• 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.
• 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.

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 Congestion on 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.