CMD Chat – Ephemerer, verschlüsselter Konsolen-Chat
Eine sichere, ausschließlich im Arbeitsspeicher laufende Konsolen-Chatlösung mit tokenbasierter Authentifizierung, sessionbasierter Verschlüsselung und optionaler TLS-Unterstützung. Ideal für vertrauliche, kurzlebige Kommunikation.



CMD Chat ist eine minimalistische und sicherheitsorientierte Chat-Anwendung für die Konsole. Alle Nachrichten existieren ausschließlich im Arbeitsspeicher (RAM) und werden standardmäßig nicht persistent gespeichert. Die Anwendung richtet sich an Nutzer, die eine Lösung für kurzfristige und vertrauliche Kommunikation benötigen, beispielsweise für interne Abstimmungen, Debugging-Sitzungen oder temporäre Dateiübertragungen.
Sicherheitskonzept
Jeder Client erzeugt beim Verbindungsaufbau ein RSA-2048-Schlüsselpaar. Über diesen Handshake wird für jede Sitzung ein symmetrischer AES-GCM-Session-Key ausgehandelt. Nachrichten werden ausschließlich im Arbeitsspeicher des Servers verarbeitet und weder gespeichert noch protokolliert.
Hinweis: Es handelt sich hierbei nicht um eine klassische Peer-to-Peer-Ende-zu-Ende-Verschlüsselung (E2EE), da der Server die Nachrichten im Arbeitsspeicher entschlüsseln kann.
Technologiestack
- Python: Implementierung von Server und Client.
- RSA-2048 & AES-GCM: Verfahren für den Schlüsselaustausch und die Nachrichtenverschlüsselung.
- Docker / docker-compose: Ermöglicht die containerisierte Bereitstellung der Anwendung.
- systemd: Dient dem optionalen Betrieb als Linux-Dienst.
Features
- Multi-Room-Funktionalität: Unterstützung mehrerer, isolierter Chat-Räume über den
/join-Befehl. - Authentifizierung: Token-basierte Zugangskontrolle über die Umgebungsvariable
CMDCHAT_TOKENS. - Transportverschlüsselung: Optionale Aktivierung von TLS für eine gesicherte Verbindung (WSS/HTTPS).
- Dateiübertragung: Segmentierte Übertragung von Dateien bis zu einer Größe von 10 MB.
- Flexible Ausgabe: Verschiedene Renderer für die Darstellung der Nachrichten (
rich,minimal,json). - Lokale Protokollierung: Optionale, clientseitig verschlüsselte Speicherung der Chat-Historie.
- Stabilität: Integriertes Rate Limiting, Heartbeats zur Verbindungserhaltung und automatische Wiederverbindungsversuche.
Screenshots und Funktionsweise
Übersicht der verbundenen Clients

Einzelansicht der Clients
Client "Aland"

Client "Tolas"

Funktionsweise: Alle abgebildeten Clients sind gleichzeitig mit demselben CMD-Chat-Server verbunden. Nach einer erfolgreichen Authentifizierung mittels Token durchläuft jeder Client folgende Schritte:
- Der Client tauscht seinen öffentlichen RSA-Schlüssel mit dem Server aus.
- Der Server generiert einen individuellen AES-Session-Key und übermittelt ihn verschlüsselt an den Client.
- Alle nachfolgenden Nachrichten werden mit diesem Sitzungsschlüssel ver- und entschlüsselt.
- Ein Client empfängt nur Nachrichten aus dem Raum, dem er beigetreten ist.
Auf diese Weise wird eine logische Kommunikation zwischen den Konsolen-Instanzen realisiert, obwohl diese in getrennten Prozessen und Terminals ausgeführt werden.
Betrieb der Anwendung
Schnellstart
git clone https://github.com/amariwan/cmd-chat.git
cd cmd-chat
python -m venv .venv
source .venv/bin/activate
pip install -e .
# Server starten
cmdchat-server
# Client verbinden
cmdchat-client --name alice
Docker
docker build -t cmdchat .
docker run -d \
--name cmdchat-server \
-p 5050:5050 \
-e CMDCHAT_TOKENS="your-secret-token" \
cmdchat
systemd
Eine vorkonfigurierte systemd-Unit (cmdchat-server.service) ist im Repository enthalten und ermöglicht eine unkomplizierte Installation für den Produktivbetrieb unter Linux.
Sicherheitshinweise
- Aktivieren Sie TLS in allen Produktionsumgebungen.
- Verwenden Sie Tokens mit hoher Entropie. Ein sicheres Token kann wie folgt generiert werden:
code
openssl rand -hex 32 - Die maximale Dateigröße für Übertragungen ist bewusst auf 10 MB beschränkt, um die Serverlast zu begrenzen.
Projektstruktur
cmd-chat/
├── cmdchat/
│ ├── server.py
│ ├── client.py
│ ├── crypto.py
│ └── protocol.py
├── Dockerfile
├── docker-compose.yml
├── SYSTEMD_INSTALL.md
└── README.md
Anwendungsfälle
- Ephemere Kommunikation in vertrauenswürdigen Netzwerkumgebungen.
- Schnelle und sichere Abstimmungen ohne persistente Chat-Historie.
- Temporäres Debugging und Austausch von Konfigurationsdateien oder Log-Ausschnitten.
Repository: https://github.com/amariwan/cmd-chat
architecture
Drei-Kern-Schichten: Client (Terminal-UI + asyncio), Server (Verbindungs-Multiplexing, Raum-Isolation, Token-Gating, Rate-Limiting) und eine Krypto-Schicht (RSA-2048-Handshake, AES-GCM-Session-Keys). Ein optionaler TLS-Gateway transportiert WSS. Nachrichten existieren ausschließlich als entschlüsselter Zustand im Prozessspeicher.
select a node to inspect responsibility, I/O, failure modes & security
- ▸Ende-zu-Ende-verschlüsselte Nachrichten pro Session (kein Klartext am Server)
- ▸Keine Persistenz von Nachrichten auf der Festplatte
- ▸Tokenbasierte Authentifizierung für den Zugriff auf Räume
- ▸Optional TLS-Transport für Produktionsbetrieb
- ▸Bereitstellung als Container oder Linux-Service
- ▸Keine externen SaaS-Abhängigkeiten — nur Python-Standardbibliothek + cryptography
- ▸Bewusst keine Datenbank; Zustand lebt im RAM
- ▸Single-Server-Modell, keine horizontale Skalierung in v1
- ▸Komfort vs. Sicherheit: kein Verlauf nach Neustart (gewollt) — kollidiert mit UX-Erwartung von Chat
- ▸Single-Server-Architektur vereinfacht Betrieb, begrenzt Skalierung auf einen Knoten
- ▸RAM-only erhöht Memory-Footprint pro Room, eliminiert aber Persistenz-Risiken
- ▸Nachrichten leben nur im RAM und werden nie auf die Festplatte geschrieben
- ▸Token-Gating über CMDCHAT_TOKENS; Rate-Limiting pro Verbindung gegen Brute-Force
- ▸Optionale WSS/TLS-Termination für Produktion; Client-seitiges Logging abwählbar
- ▸Session-Keys pro Sitzung ephemer; kein Schlüsselmaterial in Logs
- ▸Heartbeat + Reconnect-Logik im Client gegen Server-Neustarts
- ▸Container-Restart-Policy + systemd-Units sichern Selbstheilung
- ▸Slow-Loris-Schutz durch begrenzte Reader-Puffer
- ▸Manuelle Round-Trip-Tests: Handshake, Verschlüsselung, Token-Reject, Room-Isolation
- ▸Fail-Tests: Server-Neustart, Token-Expiry, TLS-Pfad
- ▸Docker-Image + docker-compose für Container-Betrieb
- ▸systemd-Unit für Bare-Metal; Ports skaliert auf TLS-Gateway
- ▸Structured Logs für Verbindungsaufbau und Auth-Events (keine Inhalte)
- ▸Metriken: offene Verbindungen, Rooms, Rate-Limit-Hits
- ▸Verschlüsselter Chat mit Null-Persistenz und Token-Auth in unter 5 min deploybar
- ▸Architektur-Referenz für spätere Security-Projekte (SSH-Hack, Orion)
- ▸Security-Requirement 'nichts speichern' muss früh die Datenmodell-Entscheidung treiben
- ▸RAM-only klingt einfach, erfordert aber Disziplin bei Logging und Fehlerpfaden
problem
Verschlüsselte, kurzlebige Team-Kommunikation ohne dauerhafte Speicherung — Chat-Verläufe dürfen nach Sitzungsende nicht rekonstruierbar sein.
context
Vertrauliche Abstimmungen und Debugging-Sessions verlangen einen Chat, der keine Beweise hinterlässt. Klassische Messenger persistieren Nachrichten oder sind nicht verschlüsselt. Ziel war eine reine Konsolenlösung, die ausschließlich im RAM lebt.