Platform
CLI - Linux (server: Docker)
Server Installation Method
Docker
Version
2.7.1
CLI Installation Method
Standalone binary
CLI Version
1.0.1
Troubleshooting
The Problem
Any host created via termix hosts create (or later edited via termix hosts update) ends up with enableSsh: false in the database, even though the schema default (schema.ts) is enableSsh: integer("enable_ssh", { mode: "boolean" }).notNull().default(true). In the web UI this shows up as the "Protocols" selector for that host appearing unset — the fix is to open the host in the UI and manually select "SSH", then save.
Root cause looks to be in the server route, not just the CLI: POST /host/db/host and PUT /host/db/host/:id (in LukeGus/Termix's src/backend/database/routes/host.ts) both build the insert/update object with:
enableSsh: enableSsh ? 1 : 0,
unconditionally, on every request — regardless of whether the request body actually included enableSsh. Since the CLI (Termix-SSH/CLI) never sends this field at all (it's not exposed as a flag — only --enable-terminal, --enable-file-manager, --enable-docker, --enable-tunnel exist in termix hosts create --help / update --help), the destructured enableSsh is undefined server-side, so undefined ? 1 : 0 evaluates to 0, overriding the DB column's own default(true).
This is different from most of the other fields in that handler, which only get added to the update object conditionally (e.g. the key field for SSH auth is only touched if (key && typeof key === "string"), so omitting it correctly leaves the stored value untouched). enableSsh/enableRdp/enableVnc/enableTelnet don't have that guard — they're always coerced to 1/0 regardless of whether the caller sent them.
How to Reproduce
termix hosts create --name test --ip <ip> --username <user> --auth-type key --key-file <path>- Open the created host in the web UI → note the "Protocols" section shows nothing selected
- Confirm via the API directly:
GET /host/db/host/{id} on the new host returns "enableSsh":false
- For comparison, create a host through the web UI instead —
enableSsh is true as expected
Additional Context
Workaround used: GET /host/db/host/{id} for the full host object, then PUT it back with enableSsh: true added explicitly (and the response-only fields like hasKey/hostKeyFingerprint/etc. stripped out first). Confirmed this doesn't disturb the stored SSH key, since that field is only touched by the handler when actually present in the request body.
Two possible fixes, either would resolve it:
- Server-side: don't force
enableSsh/enableRdp/enableVnc/enableTelnet to 0 when they're undefined in the request — only coerce when the field is actually present (matching how key/password/etc. are already handled), so the DB's own default(true) for enableSsh isn't overridden by omission.
- CLI-side: expose
--enable-ssh/--enable-rdp/--enable-vnc/--enable-telnet as flags on hosts create/hosts update (mirroring the existing --enable-terminal etc.) and default --enable-ssh to on for create, so the CLI's own request always sends an explicit value.
Happy to open a PR for either fix if useful — this was found while debugging a fresh CLI deployment, not from source-diving for its own sake.
Platform
CLI - Linux (server: Docker)
Server Installation Method
Docker
Version
2.7.1
CLI Installation Method
Standalone binary
CLI Version
1.0.1
Troubleshooting
The Problem
Any host created via
termix hosts create(or later edited viatermix hosts update) ends up withenableSsh: falsein the database, even though the schema default (schema.ts) isenableSsh: integer("enable_ssh", { mode: "boolean" }).notNull().default(true). In the web UI this shows up as the "Protocols" selector for that host appearing unset — the fix is to open the host in the UI and manually select "SSH", then save.Root cause looks to be in the server route, not just the CLI:
POST /host/db/hostandPUT /host/db/host/:id(inLukeGus/Termix'ssrc/backend/database/routes/host.ts) both build the insert/update object with:unconditionally, on every request — regardless of whether the request body actually included
enableSsh. Since the CLI (Termix-SSH/CLI) never sends this field at all (it's not exposed as a flag — only--enable-terminal,--enable-file-manager,--enable-docker,--enable-tunnelexist intermix hosts create --help/update --help), the destructuredenableSshisundefinedserver-side, soundefined ? 1 : 0evaluates to0, overriding the DB column's owndefault(true).This is different from most of the other fields in that handler, which only get added to the update object conditionally (e.g. the
keyfield for SSH auth is only touchedif (key && typeof key === "string"), so omitting it correctly leaves the stored value untouched).enableSsh/enableRdp/enableVnc/enableTelnetdon't have that guard — they're always coerced to1/0regardless of whether the caller sent them.How to Reproduce
termix hosts create --name test --ip <ip> --username <user> --auth-type key --key-file <path>GET /host/db/host/{id}on the new host returns"enableSsh":falseenableSshistrueas expectedAdditional Context
Workaround used:
GET /host/db/host/{id}for the full host object, thenPUTit back withenableSsh: trueadded explicitly (and the response-only fields likehasKey/hostKeyFingerprint/etc. stripped out first). Confirmed this doesn't disturb the stored SSH key, since that field is only touched by the handler when actually present in the request body.Two possible fixes, either would resolve it:
enableSsh/enableRdp/enableVnc/enableTelnetto0when they'reundefinedin the request — only coerce when the field is actually present (matching howkey/password/etc. are already handled), so the DB's owndefault(true)forenableSshisn't overridden by omission.--enable-ssh/--enable-rdp/--enable-vnc/--enable-telnetas flags onhosts create/hosts update(mirroring the existing--enable-terminaletc.) and default--enable-sshto on forcreate, so the CLI's own request always sends an explicit value.Happy to open a PR for either fix if useful — this was found while debugging a fresh CLI deployment, not from source-diving for its own sake.