residual/rechat
Watch
3
0
Fork
You've already forked rechat
 0
Code Issues 12 Pull requests Projects Releases Packages Wiki Activity Actions

Feature: SSH gateway — server-side TUI client over SSH (ssh.chat-style) #8

New issue
Open
opened 2026-10-16 18:26:07 +00:00 by muse-lantern · 1 comment
muse-lantern commented 2026-10-16 18:26:07 +00:00
Member
Copy link

Idea (from Zach, 2026-10-16)

Inspired by ssh.chat: run an SSH server as a zero-install client gateway. Users connect with ssh user@example.com -p 10022 and get a full rechat TUI rendered server-side through the SSH PTY — no client install needed.

Design

  • SSH server in rechat-server using golang.org/x/crypto/ssh (pure Go, no cgo — fits the stack).
  • Auth via SSH key: Ed25519 keys only — the same key format as the per-client keypairs in the auth design (issue #6). The SSH public key is registered to the account via &auth; on SSH connect the server looks up the key, resolves the account, drops into the chat TUI. The SSH key IS the client credential.
  • Optional password prompt after key auth as a second factor (server-side policy, per-account opt-in).
  • "Fake client": the official rechat TUI (Limoni) running server-side, with terminal I/O wired to the SSH session PTY instead of a local terminal.
  • Limitations of this mode (documented, not bugs): no voice (no mic path through an SSH PTY), no torrent/file upload. File viewing may work for server-hosted assets since they are already local.

Architectural implication for Stage 2

The official rechat client MUST be built with terminal I/O behind an interface (reader/writer + resize events), not hardcoded to stdin/stdout. Backends:

  • local: real terminal (normal client use)
  • ssh: SSH channel PTY (this gateway)

This keeps one TUI codebase serving both.

Scope

  • New listener in rechat-server (default port 10022, configurable; keep within the 10000-10500 test range).
  • Key registration flow: &auth command to link an SSH public key to the account (or reuse the client-key registration from #6 — SSH keys and client keys are the same Ed25519 keys).
  • Session management: one TUI session per SSH connection; concurrent with official-client sessions allowed.
  • Terminal capability handling over PTY (colors, resize/SIGWINCH).

Out of scope

  • Voice and torrent in SSH mode (documented limitation).
  • SFTP/SCP subsystem (not needed; file sharing goes through the HTTP stage-3 path).

Open questions

  • Should SSH sessions share presence/state with official-client sessions (one "device" or separate)?
  • Rate-limiting / abuse controls on the SSH listener.
  • Port choice: 10022 vs something in 10000-10500.
## Idea (from Zach, 2026-10-16) Inspired by ssh.chat: run an SSH server as a zero-install client gateway. Users connect with `ssh user@example.com -p 10022` and get a full rechat TUI rendered server-side through the SSH PTY — no client install needed. ## Design - **SSH server** in `rechat-server` using `golang.org/x/crypto/ssh` (pure Go, no cgo — fits the stack). - **Auth via SSH key**: Ed25519 keys only — the *same* key format as the per-client keypairs in the auth design (issue #6). The SSH public key is registered to the account via `&auth`; on SSH connect the server looks up the key, resolves the account, drops into the chat TUI. The SSH key IS the client credential. - **Optional password prompt** after key auth as a second factor (server-side policy, per-account opt-in). - **"Fake client"**: the official `rechat` TUI (Limoni) running server-side, with terminal I/O wired to the SSH session PTY instead of a local terminal. - **Limitations of this mode** (documented, not bugs): no voice (no mic path through an SSH PTY), no torrent/file upload. File viewing may work for server-hosted assets since they are already local. ## Architectural implication for Stage 2 The official `rechat` client MUST be built with terminal I/O behind an interface (reader/writer + resize events), not hardcoded to stdin/stdout. Backends: - `local`: real terminal (normal client use) - `ssh`: SSH channel PTY (this gateway) This keeps one TUI codebase serving both. ## Scope - New listener in `rechat-server` (default port 10022, configurable; keep within the 10000-10500 test range). - Key registration flow: `&auth` command to link an SSH public key to the account (or reuse the client-key registration from #6 — SSH keys and client keys are the same Ed25519 keys). - Session management: one TUI session per SSH connection; concurrent with official-client sessions allowed. - Terminal capability handling over PTY (colors, resize/SIGWINCH). ## Out of scope - Voice and torrent in SSH mode (documented limitation). - SFTP/SCP subsystem (not needed; file sharing goes through the HTTP stage-3 path). ## Open questions - Should SSH sessions share presence/state with official-client sessions (one "device" or separate)? - Rate-limiting / abuse controls on the SSH listener. - Port choice: 10022 vs something in 10000-10500.
muse-lantern commented 2026-10-17 01:23:28 +00:00
Author
Member
Copy link

Session vs device semantics (Zach, 2026-10-16)

  • Each SESSION counts as a separate device instance, even when sharing a key. Two SSH connections with the same key = two sessions.
  • SSH sessions are LOGGED (audit trail: timestamp, account, key fingerprint, source IP, duration, disconnect reason) but session state is NOT persisted beyond the key itself. Ephemeral by design — security posture.
  • Audit log lives separate from message storage (suggest audit.db or a table in users.db; decide at implementation).
  • Depends on the shared internal/ui package from #2.
### Session vs device semantics (Zach, 2026-10-16) - Each SESSION counts as a separate device instance, even when sharing a key. Two SSH connections with the same key = two sessions. - SSH sessions are LOGGED (audit trail: timestamp, account, key fingerprint, source IP, duration, disconnect reason) but session state is NOT persisted beyond the key itself. Ephemeral by design — security posture. - Audit log lives separate from message storage (suggest `audit.db` or a table in users.db; decide at implementation). - Depends on the shared `internal/ui` package from #2.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
residual/rechat#8
No description provided.