cmdop vs SSH
SSH is the universal baseline for reaching a shell on a machine you control — ubiquitous, battle-tested, and dead simple for one host. cmdop is not a drop-in SSH replacement; it solves the same “run things on my machines” problem from a different angle: an outbound-only gRPC relay so there are no inbound ports to open, a per-agent cryptographic identity, a fleet model for several machines, and a first-class AI chat layer over the same channel. If you have one box and a key, SSH is the right tool. If you have a handful of your own machines and want them grouped, identity-scoped, and AI-operable, cmdop adds the layers SSH leaves to you.
Shared ground
- Run commands and open interactive shells on a remote machine you own.
- Cryptographic, key-based trust rather than passwords.
- Works across the network without a third party owning your data.
Where they diverge
- SSH: a network protocol for a single client→host shell. You manage keys,
~/.ssh/config, and (for inbound) an open port or a bastion. There is no built-in fleet grouping, no agent that persists on the host beyondsshd, and no AI layer — by design, SSH is just the pipe. - cmdop: an application-layer relay mesh. Each machine runs a cmdop agent with its own Ed25519 identity, connects outbound only (no inbound ports), joins a fleet, and exposes the same channel to a web terminal, the desktop client, and an AI chat layer. Agents can also call each other via
ask_machine.
Comparison
| Dimension | cmdop | SSH |
|---|---|---|
| Reach a remote shell | Yes (web terminal + relay) | Yes (native) |
| Inbound port / bastion required | No (outbound-only relay) | Yes (or a bastion) |
| Per-agent cryptographic identity | Yes (Ed25519 per agent) | Yes (per keypair, manually managed) |
| Fleet / grouping model | Yes | No (manual config files) |
| AI chat over the same channel | Yes (jarvis + local/cloud LLM) | No |
| Agent-to-agent dispatch | Yes (ask_machine) | No |
| Ubiquity / zero install on host | No (agent required) | Yes (sshd everywhere) |
Choose SSH if…
- You need to reach one machine, occasionally, with the most universal tool that already exists everywhere.
- You want the thinnest possible pipe and prefer to manage keys and config yourself.
- The host can’t or shouldn’t run an extra agent process.
Choose cmdop if…
- You manage several of your own machines and want them grouped into a fleet with per-agent identity instead of a growing
~/.ssh/config. - You can’t (or don’t want to) open inbound ports — cmdop’s relay is outbound-only.
- You want an AI agent that can operate the machine conversationally, and machines that can ask each other for work — not just a raw shell.
The deeper distinction: the session is an object, not a socket
SSH (and tmux on top of it) binds the live session to one host socket. The session is the connection: when the socket drops, the shell’s controlling client is gone, and tmux’s local re-attach is host-bound and unattributed — several clients can attach to the same pane only locally, with no per-client identity, and only while that one host lives. cmdop makes the live execution an ownerless, addressable object: it is single-homed on one host but owned by no client, reached by session identity rather than by holding a socket, and re-attachable from any device over the relay with per-operator attribution and transferable authority. SSH gives you a pipe to a host; cmdop gives the running execution its own identity that outlives whichever client is currently holding it.
Honest verdict
SSH is simpler, more universal, and has zero install footprint on the host — for a single box it is hard to beat. cmdop does not replace SSH so much as wrap the same goal in a private mesh with identity, fleets, and an AI layer. Many cmdop users still keep SSH for the odd one-off host; cmdop earns its place once you have several machines you personally own and want them operable as a group, by you and by an AI, without managing inbound access.
See also: Identity & the private contour · AI chat · Agent communication.
TAGS: comparison, ssh, machine-access
Cmdop