hermes - 💡(How to fix) Fix [Bug]: hermes doctor SSH check ignores configured SSH user/port/key

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

Error Message

Additional Logs / Traceback (optional)

Root Cause

Root Cause Analysis (optional)

Fix Action

Fix / Workaround

Before adding `StrictHostKeyChecking=accept-new` to the doctor probe locally, the patched doctor command failed with:

Code Example

TERMINAL_ENV=ssh
TERMINAL_SSH_HOST=hermes-terminal
TERMINAL_SSH_USER=hermes
TERMINAL_SSH_PORT=22
TERMINAL_SSH_KEY=/opt/data/ssh/hermes_terminal

---

ssh -i /opt/data/ssh/hermes_terminal -p 22 hermes@hermes-terminal echo ok

---

hermes doctor

---

SSH connection to hermes-terminal

---

SSH connection to hermes-terminal

---

SSH connection to hermes-terminal

---

ok

---

--- hermes dump ---
version:          0.14.0 (2026.5.16) [(unknown)]
os:               Linux 6.18.29+rpt-rpi-2712 aarch64
python:           3.13.5
openai_sdk:       2.24.0
profile:          default
hermes_home:      /opt/data
model:            openrouter/owl-alpha
provider:         openrouter
terminal:         ssh

api_keys:
  openrouter           set
  openai               not set
  anthropic            not set
  anthropic_token      not set
  nous                 not set
  google/gemini        not set
  gemini               not set
  glm/zai              not set
  zai                  not set
  kimi                 not set
  minimax              not set
  deepseek             not set
  dashscope            not set
  huggingface          not set
  nvidia               not set
  ai_gateway           not set
  opencode_zen         not set
  opencode_go          not set
  kilocode             not set
  firecrawl            not set
  tavily               not set
  browserbase          not set
  fal                  not set
  elevenlabs           not set
  github               not set

features:
  toolsets:           [, ", h, e, r, m, e, s, -, c, l, i, ", ,,  , ", b, r, o, w, s, e, r, ", ]
  mcp_servers:        0
  memory_provider:    built-in
  gateway:            running (docker (foreground), pid 7)
  platforms:          telegram
  cron_jobs:          1 active / 1 total
  skills:             87

config_overrides:
  terminal.backend: ssh
  display.streaming: True
  toolsets: ["hermes-cli", "browser"]
--- end dump ---

---

Before adding `StrictHostKeyChecking=accept-new` to the doctor probe locally, the patched doctor command failed with:

Host key verification failed.

---

["ssh", "-o", "ConnectTimeout=5", "-o", "BatchMode=yes", ssh_host, "echo ok"]

---

Host key verification failed.

---

SSH connection to <host>

---

ssh -i /opt/data/ssh/hermes_terminal -p 22 hermes@hermes-terminal echo ok

---

ssh_host = os.getenv("TERMINAL_SSH_HOST")
ssh_user = os.getenv("TERMINAL_SSH_USER")
ssh_port = os.getenv("TERMINAL_SSH_PORT")
ssh_key = os.getenv("TERMINAL_SSH_KEY")

ssh_target = f"{ssh_user}@{ssh_host}" if ssh_user else ssh_host

ssh_cmd = [
    "ssh",
    "-o", "ConnectTimeout=5",
    "-o", "BatchMode=yes",
    "-o", "StrictHostKeyChecking=accept-new",
]

if ssh_key:
    ssh_cmd += ["-i", ssh_key]
if ssh_port:
    ssh_cmd += ["-p", ssh_port]

ssh_cmd += [ssh_target, "echo ok"]
RAW_BUFFERClick to expand / collapse

Bug Description

hermes doctor reports a failed SSH connection when TERMINAL_ENV=ssh is configured with an explicit SSH user, port, and private key.

The actual terminal backend works correctly with that configuration: Hermes can run terminal commands over SSH using the configured key.

The problem is only the doctor SSH health check: it appears to probe the host without applying TERMINAL_SSH_USER, TERMINAL_SSH_PORT, and TERMINAL_SSH_KEY, so it reports SSH as broken even though the runtime backend is healthy.

Steps to Reproduce

  1. Configure the SSH terminal backend with a non-default SSH user/key:
TERMINAL_ENV=ssh
TERMINAL_SSH_HOST=hermes-terminal
TERMINAL_SSH_USER=hermes
TERMINAL_SSH_PORT=22
TERMINAL_SSH_KEY=/opt/data/ssh/hermes_terminal
  1. Verify that the configured SSH connection works:
ssh -i /opt/data/ssh/hermes_terminal -p 22 hermes@hermes-terminal echo ok
  1. Run:
hermes doctor
  1. Observe that doctor reports:
✗ SSH connection to hermes-terminal

Expected Behavior

hermes doctor should validate the SSH backend using the same SSH configuration as the runtime backend.

With the env vars above, it should report:

✓ SSH connection to hermes-terminal

Actual Behavior

hermes doctor reports:

✗ SSH connection to hermes-terminal

even though runtime terminal commands over SSH work correctly. Manually running the equivalent fully configured SSH command succeeds:

ok

So the SSH backend itself is not broken. The failure appears specific to the doctor connectivity probe.

Affected Component

Tools (terminal, file ops, web, code execution, etc.)

Messaging Platform (if gateway-related)

No response

Debug Report

--- hermes dump ---
version:          0.14.0 (2026.5.16) [(unknown)]
os:               Linux 6.18.29+rpt-rpi-2712 aarch64
python:           3.13.5
openai_sdk:       2.24.0
profile:          default
hermes_home:      /opt/data
model:            openrouter/owl-alpha
provider:         openrouter
terminal:         ssh

api_keys:
  openrouter           set
  openai               not set
  anthropic            not set
  anthropic_token      not set
  nous                 not set
  google/gemini        not set
  gemini               not set
  glm/zai              not set
  zai                  not set
  kimi                 not set
  minimax              not set
  deepseek             not set
  dashscope            not set
  huggingface          not set
  nvidia               not set
  ai_gateway           not set
  opencode_zen         not set
  opencode_go          not set
  kilocode             not set
  firecrawl            not set
  tavily               not set
  browserbase          not set
  fal                  not set
  elevenlabs           not set
  github               not set

features:
  toolsets:           [, ", h, e, r, m, e, s, -, c, l, i, ", ,,  , ", b, r, o, w, s, e, r, ", ]
  mcp_servers:        0
  memory_provider:    built-in
  gateway:            running (docker (foreground), pid 7)
  platforms:          telegram
  cron_jobs:          1 active / 1 total
  skills:             87

config_overrides:
  terminal.backend: ssh
  display.streaming: True
  toolsets: ["hermes-cli", "browser"]
--- end dump ---

Operating System

Docker container based on nousresearch/hermes-agent:latest

Python Version

Python 3.13.5

Hermes Version

Hermes Agent v0.14.0 (2026.5.16)

Additional Logs / Traceback (optional)

Before adding `StrictHostKeyChecking=accept-new` to the doctor probe locally, the patched doctor command failed with:

Host key verification failed.

Root Cause Analysis (optional)

The issue appears to be in hermes_cli/doctor.py, in the SSH backend check.

When TERMINAL_ENV=ssh, doctor checks connectivity with a simplified command similar to:

["ssh", "-o", "ConnectTimeout=5", "-o", "BatchMode=yes", ssh_host, "echo ok"]

This does not use the configured SSH backend settings:

  • TERMINAL_SSH_USER
  • TERMINAL_SSH_PORT
  • TERMINAL_SSH_KEY

The documented SSH backend behavior says the SSH connection is opened with:

  • BatchMode=yes
  • StrictHostKeyChecking=accept-new

doctor already uses BatchMode=yes, but it does not include StrictHostKeyChecking=accept-new in its SSH probe. This can make doctor fail with:

Host key verification failed.

As a result, the actual Hermes terminal backend can work correctly, while hermes doctor still reports:

✗ SSH connection to <host>

In my setup, the runtime terminal tool successfully connects with:

ssh -i /opt/data/ssh/hermes_terminal -p 22 hermes@hermes-terminal echo ok

but hermes doctor fails because its check does not include the configured user/key/port and host key policy.

Proposed Fix (optional)

Update the SSH connectivity check in hermes_cli/doctor.py to build the test command from the same environment variables used by the SSH terminal backend.

Suggested behavior:

ssh_host = os.getenv("TERMINAL_SSH_HOST")
ssh_user = os.getenv("TERMINAL_SSH_USER")
ssh_port = os.getenv("TERMINAL_SSH_PORT")
ssh_key = os.getenv("TERMINAL_SSH_KEY")

ssh_target = f"{ssh_user}@{ssh_host}" if ssh_user else ssh_host

ssh_cmd = [
    "ssh",
    "-o", "ConnectTimeout=5",
    "-o", "BatchMode=yes",
    "-o", "StrictHostKeyChecking=accept-new",
]

if ssh_key:
    ssh_cmd += ["-i", ssh_key]
if ssh_port:
    ssh_cmd += ["-p", ssh_port]

ssh_cmd += [ssh_target, "echo ok"]

This makes hermes doctor validate the same SSH configuration that the runtime terminal backend uses.

Are you willing to submit a PR for this?

  • I'd like to fix this myself and submit a PR

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING