ssh-mcp-pro 1.1.4 → 1.2.1

package/docs/security/dependency-audit-exceptions.json

@@ -0,0 +1,4 @@
+{
+  "version": 1,
+  "exceptions": []
+}

package/docs/security/dependency-audit-exceptions.md

@@ -0,0 +1,15 @@
+# Dependency Audit Exceptions
+
+Dependency audit exceptions are a last resort. They must be scoped to a specific distribution surface, include reachability evidence, name an owner, define a removal condition, and expire automatically. The machine-readable source of truth is [`dependency-audit-exceptions.json`](./dependency-audit-exceptions.json).
+
+The canonical workspace, Docker image, and release lockfile must remain free of known moderate-or-higher advisories. `pnpm run audit:packed` separately installs the generated npm tarball as an external consumer and rejects every advisory that is not listed in the exception file. It also rejects expired or stale exceptions.
+
+## Active exception
+
+| Advisory | Package path | Scope | Reachability assessment | Owner | Expires |
+| --- | --- | --- | --- | --- | --- |
+| `GHSA-frvp-7c67-39w9` | `ssh-mcp-pro > @modelcontextprotocol/sdk > @hono/node-server` | Published npm consumer graph | The affected `serve-static` implementation is not imported or invoked by ssh-mcp-pro. HTTP entrypoints use the project's own Node HTTP implementation. | `@oaslananka` | 2026-08-23 |
+
+The latest `@modelcontextprotocol/sdk` release still constrains `@hono/node-server` to the vulnerable 1.x major. Local, CI, and container installs use the patched 2.x major through the root workspace override. npm consumers do not inherit dependency-package overrides, so the exception remains visible only for the independently installed tarball.
+
+Remove the exception immediately when the MCP SDK accepts `@hono/node-server >=2.0.5`, or before introducing any use of the Hono Node adapter or `serve-static`.

package/docs/security/input-validation.md

@@ -0,0 +1,54 @@
+# Input Validation
+
+This summarizes where and how untrusted input is constrained, based on the environment
+variables and policy behavior already documented in the
+[README configuration table](../../README.md#configuration) and
+[SECURITY_DECISIONS.md](../../SECURITY_DECISIONS.md). It intentionally stays at the
+policy level rather than asserting internal implementation details this audit didn't
+verify line-by-line.
+
+## Schema-level validation
+
+Tool inputs are validated with [zod](https://www.npmjs.com/package/zod) schemas (a
+runtime dependency in `package.json`); policy file contents are checked against JSON
+Schema tooling (`ajv` is a devDependency used in the validation scripts under
+`scripts/`). Malformed input is expected to be rejected before it reaches SSH/filesystem
+operations, rather than sanitized and passed through.
+
+## Allow/deny lists, not blanket flags
+
+Most of the security-relevant configuration surface is an allow/deny pair rather than a
+single boolean, specifically so operators can scope access narrowly instead of an
+all-or-nothing switch:
+
+- `SSH_MCP_ALLOWED_HOSTS` / implicit deny of everything else.
+- `SSH_MCP_COMMAND_ALLOW` / `SSH_MCP_COMMAND_DENY`.
+- `SSH_MCP_PATH_ALLOW_PREFIXES` / `SSH_MCP_PATH_DENY_PREFIXES` (remote filesystem).
+- `SSH_MCP_LOCAL_PATH_ALLOW_PREFIXES` / `SSH_MCP_LOCAL_PATH_DENY_PREFIXES` (local
+  transfer endpoints).
+- `SSH_MCP_TUNNEL_ALLOW_BIND_HOSTS` / `SSH_MCP_TUNNEL_DENY_BIND_HOSTS` and the
+  equivalent remote-host/port allow/deny pairs for tunnels.
+
+Deny lists are checked in addition to allow lists — see
+[docs/how-to/configure-ssh-policy.md](../how-to/configure-ssh-policy.md) for how to use
+both together.
+
+## Size/resource bounds
+
+Every buffer- or transfer-related setting has an explicit byte ceiling:
+`SSH_MCP_MAX_COMMAND_OUTPUT_BYTES`, `SSH_MCP_MAX_FILE_SIZE`,
+`SSH_MCP_MAX_FILE_WRITE_BYTES`, `SSH_MCP_MAX_TRANSFER_BYTES`,
+`SSH_MCP_HTTP_MAX_REQUEST_BODY_BYTES`, and stream/session ceilings
+(`SSH_MCP_MAX_STREAM_CHUNKS`, `SSH_MCP_MAX_SESSIONS`, `SSH_MCP_HTTP_MAX_SESSIONS`). These
+exist to bound both memory use and the blast radius of any single tool call.
+
+## Resolved gap (was: known gap)
+
+Several CodeQL alerts (`js/file-access-to-http` / `js/http-to-file-access` in
+`src/remote/agent-cli.ts` and `scripts/check-dependency-freshness.mjs`) were exactly
+input-validation-shaped findings — untrusted file data influencing a network request, or
+untrusted network data influencing a file write. As of 2026-07-03 all were dismissed
+after independently re-verifying the rationale in `SECURITY_DECISIONS.md` against the
+current code (not just re-asserting stale documentation) — see
+[docs/repo-maturity-report.md](../repo-maturity-report.md) for the audit trail. 0 open
+CodeQL alerts remain.

package/docs/security/release-integrity.md

@@ -0,0 +1,28 @@
+# Release Integrity
+
+How a release artifact can be verified, and what mechanism backs each guarantee. See
+[docs/development/release-process.md](../development/release-process.md) for the full
+release flow this is extracted from.
+
+| Guarantee | Mechanism | Verify with |
+| --- | --- | --- |
+| The tarball wasn't corrupted/tampered in transit | SHA-256 checksum generated in `release-assets` (`sha256sum "artifacts/${PACKAGE_FILE}" > ...sha256`) | `sha256sum -c ssh-mcp-pro-<version>.tgz.sha256` |
+| The tarball was actually built by this repo's release workflow, from the commit it claims | `actions/attest-build-provenance` on the package | `gh attestation verify ssh-mcp-pro-<version>.tgz --owner oaslananka` |
+| The SBOM matches the released package and wasn't tampered with | Separate checksum + separate `actions/attest-build-provenance` run with `sbom-path` set | `sha256sum -c sbom.cdx.json.sha256`, `gh attestation verify sbom.cdx.json --owner oaslananka` |
+| What's actually inside the package (dependency inventory) | CycloneDX SBOM (`pnpm run sbom`) | Inspect `sbom.cdx.json` directly, or feed it to any CycloneDX-compatible scanner |
+| npm package provenance (when published) | `npm publish --provenance` (conditional on `AUTO_RELEASE_PUBLISH` repo variable) | `npm view ssh-mcp-pro provenance`, or the "Provenance" panel on the npmjs.com package page |
+| Container image integrity | Digest-pinned references, no mutable `latest` tag | See [docs/docker.md](../docker.md) |
+
+## Current limitation
+
+None of the above has been exercised against a real release yet — no release has been
+published (see [docs/repo-maturity-report.md](../repo-maturity-report.md)). The
+mechanisms are implemented and reviewed here on paper; they should be spot-checked
+against the first actual release before being relied on operationally.
+
+## What this does *not* claim
+
+This project does not claim a specific SLSA build level. `actions/attest-build-provenance`
+produces build provenance attestations (in-toto/SLSA-compatible statements), which is a
+meaningfully strong signal, but claiming a specific SLSA level requires meeting that
+level's full requirement set — not attempted here to avoid overclaiming.

package/docs/security/scanning-policy.md

@@ -0,0 +1,50 @@
+# Security scanning policy
+
+This repository uses complementary scanners because no single tool covers source code,
+dependencies, secrets, workflow configuration, and container images equally well.
+
+## Required controls
+
+| Surface | Primary control | Enforcement |
+| --- | --- | --- |
+| TypeScript and workflows | CodeQL, Semgrep, and SonarQube Cloud | Required pull-request checks where configured |
+| Dependency graph | `pnpm audit`, dependency review, Socket, and OSV verification | Moderate-or-higher audit findings fail the canonical quality gate unless a reviewed, expiring exception exists |
+| Secrets | Gitleaks, SonarQube secrets, and Trivy filesystem scanning | New verified findings block merge |
+| Container image | Trivy | Fixable High and Critical vulnerabilities fail the Docker workflow |
+| Release artifacts | SBOM, package smoke tests, provenance, and registry metadata checks | Required before publishing |
+
+## Container policy
+
+The Docker workflow performs two scans against the image built from the pull-request or
+release commit:
+
+1. A SARIF scan reports all High and Critical findings to GitHub code scanning.
+2. A separate enforcement scan fails on **fixable** High or Critical vulnerabilities.
+
+`ignore-unfixed: true` is intentionally limited to the enforcement scan. Unfixed findings
+remain visible in SARIF and must be reconsidered when a fix becomes available. The project
+does not maintain wildcard ignores or an indefinite `.trivyignore` baseline. A temporary
+exception must identify the advisory, explain the exposure, name an owner, and include an
+expiry date in a reviewed repository file or issue.
+
+Short-lived test-runner images, such as `Dockerfile.test`, are not required to define a
+`HEALTHCHECK`; they do not run a service and exit when the test command completes.
+
+## Local verification
+
+```bash
+osv-scanner scan source --recursive .
+semgrep ci --dry-run
+trivy fs --skip-dirs node_modules --scanners vuln,misconfig,secret .
+```
+
+Container enforcement requires Docker access:
+
+```bash
+docker build -t ssh-mcp-pro:local .
+trivy image --scanners vuln --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 ssh-mcp-pro:local
+```
+
+Scanner output is evidence, not an automatic code-change mandate. Protocol-required
+cryptography, bounded configuration regexes, and short-lived build images must be reviewed
+in context rather than changed solely to silence a generic rule.

package/docs/security/secrets-management.md

@@ -0,0 +1,49 @@
+# Secrets Management
+
+Covers both how ssh-mcp-pro handles secrets at runtime, and how this repository's own
+CI/CD handles secrets. No secrets, tokens, or credentials were added to the repository
+by this audit — this document only records what already exists.
+
+## Runtime (the deployed server)
+
+- **Bearer tokens are read from a file** (`SSH_MCP_HTTP_BEARER_TOKEN_FILE`), not passed
+  directly as an environment variable value, reducing exposure via process listings and
+  environment dumps.
+- **Bearer token comparison uses `timingSafeEqual`** (documented in
+  `SECURITY_DECISIONS.md`), avoiding timing side-channels.
+- **Connector credential providers** (`SSH_MCP_CONNECTOR_CREDENTIAL_PROVIDER=command`)
+  resolve credentials via an external command rather than storing them in configuration,
+  and reject command output containing forbidden secret-shaped fields (see
+  `test/unit/connector-credentials.test.ts`).
+- **Audit logging redacts sensitive fields** per `SECURITY_DECISIONS.md`, within a
+  bounded 500-event buffer.
+- **Resolved (was: known open gap):** CodeQL alert #1 (High) flagged clear-text logging
+  of sensitive environment data in `scripts/start-chatgpt-http.mjs` — a genuine secrets
+  handling defect. Fixed 2026-07-03 by deriving the logged values from already-validated
+  enum checks instead of interpolating environment-sourced strings directly; see
+  [docs/repo-maturity-report.md](../repo-maturity-report.md) for the audit trail.
+
+## CI/CD
+
+- **No long-lived npm token.** The release workflow explicitly `unset`s
+  `NODE_AUTH_TOKEN`/`NPM_CONFIG_USERCONFIG` before publishing and relies on
+  `id-token: write` + `npm publish --provenance` — npm's OIDC trusted-publishing flow,
+  not a stored secret. See [docs/security/release-integrity.md](release-integrity.md).
+- **No Docker registry password stored** — GHCR login uses `${{ github.token }}`
+  (the automatically-provisioned, workflow-scoped token), not a personal access token.
+- **This audit's own `gitleaks.yml` addition uses `${{ secrets.GITHUB_TOKEN }}`** —
+  the same automatic token, required by `gitleaks-action` v3 to scan pull requests. No
+  new secret was created or requested.
+- **GitHub secret scanning + push protection are enabled** at the repository level
+  (confirmed via API), catching accidental secret commits before they're even pushed.
+- **`.env.example` exists** and should be the only `.env*`-shaped file ever committed;
+  `.gitignore` is expected to exclude real `.env` files (verify locally if adding new
+  env-derived tooling).
+
+## If you're adding a new CI step that needs credentials
+
+Before adding any token: check whether OIDC/trusted-publishing is available for the
+target platform first (npm and PyPI both support it; GHCR uses the automatic
+`GITHUB_TOKEN`). Long-lived tokens should be a last resort, not a default — see the
+constraints this audit operated under in
+[docs/repo-maturity-report.md](../repo-maturity-report.md).

package/docs/security/threat-model.md

@@ -0,0 +1,65 @@
+# Threat Model
+
+This document states the threat model implied by the defaults already documented in
+[SECURITY_DECISIONS.md](../../SECURITY_DECISIONS.md) and the README's
+[Security Defaults](../../README.md#security-defaults) section, gathered into one place.
+It does not introduce new claims about the implementation beyond what those documents
+already assert.
+
+## What ssh-mcp-pro is
+
+An MCP server that gives an LLM-driven client a curated set of tools for opening SSH
+sessions and running commands, transferring files, managing services, and creating
+tunnels against remote hosts, mediated by a policy layer.
+
+## Primary actors
+
+| Actor | Trust level | Notes |
+| --- | --- | --- |
+| The MCP client (e.g. an LLM agent) | Partially trusted | Can issue any tool call the active [tool profile](../../README.md#tool-profiles) exposes; instructions reaching it may be ambiguous or, in the worst case, adversarial (prompt injection via tool output, a compromised upstream, etc.) |
+| The operator/deployer | Trusted | Configures policy, environment variables, and which hosts are reachable |
+| The remote SSH host | Partially trusted | Assumed to be a host the operator intends to manage, but output from it (command results, file contents) is untrusted data flowing back into the MCP session |
+| A remote connector caller (HTTP transport) | Least trusted | Reaches the server over a network boundary; see the non-loopback HTTP restrictions below |
+
+## What the defaults are actually defending against
+
+1. **An LLM client instructed (by a user, a compromised prompt, or a malicious tool
+   response) to do something destructive.** This is why destructive commands and
+   filesystem operations (`fs_rmrf`, etc.) are denied by default
+   (`SSH_MCP_ALLOW_DESTRUCTIVE_COMMANDS`, `SSH_MCP_ALLOW_DESTRUCTIVE_FS`), and why root
+   login and raw `sudo` are denied by default.
+2. **Host impersonation / MITM against a managed host.** This is why
+   `SSH_MCP_HOST_KEY_POLICY` defaults to `strict` against a known-hosts file rather than
+   trusting on first use.
+3. **Accidental exposure of the server itself to the network.** This is why non-loopback
+   HTTP startup requires an explicit combination of bearer/OAuth auth, an allowed
+   origins list, a public HTTPS URL, strict host-key verification, a remote-safe tool
+   profile, and a host allowlist — the server refuses to start non-loopback without all
+   of these, rather than silently binding wide open.
+4. **Overexposure to untrusted/broad connector audiences.** This is why tool profiles
+   (`remote-safe`, `chatgpt`, `claude`, `remote-readonly`, `remote-broker`) are
+   allowlists of a small tool subset, not the full `full` profile, for anything meant to
+   be reachable by a broader audience than a trusted local stdio client.
+5. **Credential/secret leakage through logs or audit trails.** `SECURITY_DECISIONS.md`
+   documents audit redaction patterns and a bounded (500-event) audit buffer, and
+   constant-time (`timingSafeEqual`) comparison for bearer tokens.
+
+## Resolved gap (was: known open gap)
+
+CodeQL previously had 7 open alerts, including one High severity finding
+(`js/clear-text-logging` in `scripts/start-chatgpt-http.mjs`) that was exactly the kind
+of secret-leakage-through-logs risk this threat model calls out. All 8 were resolved
+2026-07-03 (1 fixed in code, 7 dismissed with re-verified rationale) — see
+[docs/repo-maturity-report.md](../repo-maturity-report.md) for the audit trail. Separately,
+adding Trivy container-image scanning the same day surfaced 50+ new findings against the
+built Docker image (mostly the base image's bundled tooling, not this project's own
+code) — see "Package publishing maturity" in that same report. That backlog is
+untriaged as of this update and is the current live example of "detection isn't the
+same as resolution."
+
+## Out of scope (matches SECURITY.md)
+
+- Vulnerabilities in dependencies that aren't reachable through this project's own
+  attack surface.
+- Findings that require the operator to have already disabled a secure default.
+- Denial-of-service against a fully trusted local development environment.

package/docs/testing.md

@@ -1,5 +1,29 @@
 # Testing
 
+## HTTP boundary testing
+
+`test/integration/http-server-boundary.integration.test.ts` starts the real HTTP
+MCP runtime in-process on an ephemeral loopback port. It uses temporary bearer
+files, an injected clock, and deterministic remote-control-plane doubles; it
+does not require external OAuth, JWKS, SSH, or public-network services.
+
+The suite exercises the production request boundary rather than only helper
+functions. Coverage includes bearer and OAuth challenges, origin and CORS
+handling, request-size limits, rate-limit headers, protected-resource metadata,
+MCP session initialization, capacity eviction, idle expiry, legacy SSE,
+remote HTTP and WebSocket delegation, startup refusal, and idempotent shutdown.
+`test/unit/http-server-lifecycle.test.ts` separately locks lifecycle concurrency,
+bind failures, signal cleanup, and one-shot close behavior.
+
+Run the boundary suite with:
+
+```bash
+pnpm run test:integration -- test/integration/http-server-boundary.integration.test.ts
+```
+
+The HTTP runtime is included in the normal coverage denominator. Do not replace
+these tests with a coverage exclusion when adding routes or lifecycle branches.
+
 ## Mutation testing
 
 Mutation testing is configured for policy-critical security surfaces only. The

package/docs/troubleshooting.md

@@ -0,0 +1,56 @@
+# Troubleshooting
+
+Common failure modes and where to look. For option-by-option config, see
+[docs/reference/configuration.md](reference/configuration.md).
+
+## The server starts but no tools show up in my MCP client
+
+Check `SSH_MCP_TOOL_PROFILE` (or `--tool-profile`). Every profile except `full` is an
+allowlist — see [Tool Profiles](../README.md#tool-profiles). If you expected the full
+tool set and see only a handful, you're likely on `remote-safe` or another restricted
+profile.
+
+## `EHOSTKEY` / host key verification failures
+
+This is `SSH_MCP_HOST_KEY_POLICY=strict` (the default) working as intended: the host
+isn't in `SSH_MCP_KNOWN_HOSTS_PATH` yet, or its key changed. Add the host's key to your
+known_hosts file first (e.g. `ssh-keyscan` then verify out-of-band), or see
+[docs/how-to/configure-ssh-policy.md](how-to/configure-ssh-policy.md) for
+lab-environment alternatives. Do not switch to `insecure` against a host you don't fully
+trust.
+
+## A tool call is denied by policy
+
+Run `ssh_policy_explain` (or ask your MCP client to "explain the active SSH policy")
+before assuming something is broken — most denials are the deny-by-default security
+posture described in [SECURITY_DECISIONS.md](../SECURITY_DECISIONS.md), not a bug. See
+[docs/how-to/configure-ssh-policy.md](how-to/configure-ssh-policy.md) to loosen a
+specific restriction deliberately.
+
+## Non-loopback HTTP transport won't start
+
+By design — see [Security Defaults](../README.md#security-defaults). Non-loopback
+startup requires bearer/OAuth auth, an allowed origins list, a public HTTPS URL, strict
+host-key verification, a remote-safe tool profile, and a host allowlist, all configured
+together. Check the startup error message; it names which of these is missing.
+
+## Debugging a session
+
+Set `SSH_MCP_DEBUG=true` for more verbose configuration-time diagnostics. For
+request/response-level detail, check whether OpenTelemetry export is configured (see the
+`@opentelemetry/*` dependencies and the telemetry-related environment variables) — this
+project ships OTLP trace export support, not just console logging.
+
+## Windows-specific SSH integration issues
+
+There's a dedicated Windows SSH integration test project
+(`pnpm run test:integration:windows`) — if something works on Linux but not Windows,
+check that test file first; it's the closest thing to a regression harness for
+Windows-specific SSH behavior.
+
+## Filing a bug
+
+If none of the above resolves it, open an issue using the bug report template — see
+[SUPPORT.md](../SUPPORT.md) for response expectations. Include the output of
+`ssh_policy_explain` and the exact `SSH_MCP_*` environment variables you've set
+(redacting any secrets).

package/docs/tutorials/getting-started.md

@@ -0,0 +1,84 @@
+# Tutorial: Getting Started
+
+This is a learning-oriented walkthrough: follow it top to bottom and you'll end with a
+working local ssh-mcp-pro connected to an MCP client and one successful remote command.
+Per [Diátaxis](https://diataxis.fr/tutorials/), it favors one guaranteed-to-work path
+over covering every option — see [How-to guides](../how-to/README.md) for other tasks
+and [Reference](../reference/README.md) for the full option set.
+
+## 1. Prerequisites
+
+You need:
+
+- Node.js `>=22.22.2` (or `>=24.15.0` / `>=26.3.0`) and pnpm `>=11.0.9`.
+- At least one host you can already reach with plain `ssh`, with its key already in
+  your `~/.ssh/known_hosts` (this tutorial uses the default `strict` host-key policy —
+  see [SECURITY_DECISIONS.md](../../SECURITY_DECISIONS.md) for why).
+
+## 2. Install
+
+```bash
+pnpm add --global ssh-mcp-pro
+ssh-mcp-pro --version
+```
+
+If that prints a version number, installation worked.
+
+## 3. Register it with an MCP client
+
+Pick the block matching your client and add it to that client's MCP config (see
+[INSTALL.md](../../INSTALL.md) for exact file locations per client):
+
+```json
+{
+  "mcpServers": {
+    "ssh-mcp-pro": {
+      "command": "ssh-mcp-pro",
+      "args": []
+    }
+  }
+}
+```
+
+Restart or reload your MCP client so it picks up the new server.
+
+## 4. Confirm the server is visible
+
+In your MCP client, ask it to list available tools, or run:
+
+```text
+List configured SSH hosts.
+```
+
+You should see a response describing zero or more configured hosts — an empty list is
+expected if you haven't pointed `ssh-mcp-pro` at any host config yet; it means the
+server started and responded, which is the thing this step is actually checking.
+
+## 5. Inspect the active policy
+
+Before running anything against a real host, see what's allowed:
+
+```text
+Explain the active SSH policy.
+```
+
+This reflects the deny-by-default settings described in the
+[Security Defaults](../../README.md#security-defaults) section of the README: strict
+host-key checking, no root login, no raw `sudo`, no destructive operations.
+
+## 6. Connect to a host and run a safe, read-only command
+
+```text
+Connect to <your-host> as <your-user> with hostKeyPolicy=strict, then run os_detect.
+```
+
+If this succeeds, you have a working end-to-end setup: MCP client → ssh-mcp-pro →
+your host.
+
+## Next steps
+
+- [How to configure the SSH policy](../how-to/configure-ssh-policy.md) if you need to
+  change any default.
+- [examples/README.md](../../examples/README.md) for more workflow examples.
+- [docs/explanation/architecture.md](../explanation/architecture.md) to understand why
+  the server is structured the way it is.

package/mcp.json

@@ -2,7 +2,7 @@
   "name": "ssh-mcp-pro",
   "display_name": "ssh-mcp-pro",
   "description": "Secure MCP SSH automation server with policy controls, resources, prompts, stdio, and HTTP.",
-  "version": "1.1.4",
+  "version": "1.2.1",
   "author": "Osman Aslan",
   "license": "MIT",
   "runtime": "node",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "ssh-mcp-pro",
-  "version": "1.1.4",
+  "version": "1.2.1",
   "mcpName": "io.github.oaslananka/ssh-mcp-pro",
   "description": "Model Context Protocol (MCP) SSH client server for remote automation",
   "type": "module",
@@ -58,17 +58,18 @@
   },
   "engines": {
     "node": ">=22.22.2",
-    "pnpm": "^11.5.1"
+    "pnpm": "^11.28.5"
   },
   "dependencies": {
-    "@modelcontextprotocol/sdk": "^1.29.0",
+    "@modelcontextprotocol/sdk": "^1.32.0",
     "@opentelemetry/api": "^1.9.1",
-    "@opentelemetry/exporter-trace-otlp-http": "^0.219.0",
-    "@opentelemetry/resources": "^2.8.0",
-    "@opentelemetry/sdk-node": "^0.219.0",
-    "@opentelemetry/semantic-conventions": "^1.41.1",
+    "@opentelemetry/exporter-trace-otlp-http": "^0.222.0",
+    "@opentelemetry/resources": "^2.11.0",
+    "@opentelemetry/sdk-node": "^0.222.0",
+    "@opentelemetry/semantic-conventions": "^1.43.0",
     "jose": "6.2.3",
     "node-ssh": "^13.2.1",
+    "ws": "^8.21.1",
     "zod": "^4.4.3"
   },
   "devDependencies": {
@@ -76,21 +77,33 @@
     "@stryker-mutator/typescript-checker": "9.6.1",
     "@stryker-mutator/vitest-runner": "9.6.1",
     "@types/node": "^24.13.1",
-    "@types/ssh2": "^1.15.5",
-    "@typescript-eslint/eslint-plugin": "^8.61.0",
-    "@typescript-eslint/parser": "^8.61.0",
-    "@vitest/coverage-v8": "^4.1.8",
+    "@types/ssh2": "^1.15.6",
+    "@types/ws": "^8.18.2",
+    "@typescript-eslint/eslint-plugin": "^8.71.0",
+    "@typescript-eslint/parser": "^8.71.0",
+    "@vitest/coverage-v8": "^4.1.11",
     "ajv": "^8.20.0",
     "autocannon": "^7.15.0",
     "dependency-cruiser": "^17.4.3",
-    "eslint": "^10.4.1",
-    "fast-check": "^4.8.0",
-    "knip": "^6.16.1",
-    "prettier": "^3.8.4",
-    "typedoc": "0.28.19",
+    "eslint": "^10.12.0",
+    "fast-check": "^4.10.2",
+    "knip": "^6.39.0",
+    "prettier": "^3.9.9",
+    "publint": "^0.3.25",
+    "typedoc": "0.28.20",
     "typescript": "^6.0.3",
     "vite": "^7.3.5",
-    "vitest": "^4.1.8"
+    "vitest": "^4.1.11"
+  },
+  "overrides": {
+    "brace-expansion": "^5.0.12",
+    "fast-uri": "^3.1.8",
+    "ip-address": "^10.7.1",
+    "nanoid": "^3.3.18",
+    "browserslist": "^4.28.7",
+    "@hono/node-server": "^2.0.5",
+    "markdown-it": "^14.3.2",
+    "vitest": "^4.1.11"
   },
   "scripts": {
     "build": "tsc -p tsconfig.json",
@@ -112,12 +125,16 @@
     "format:check": "prettier --check \"src/**/*.ts\" \"test/**/*.ts\" \"scripts/**/*.{mjs,cjs}\" \"docs/**/*.md\" \".github/workflows/*.{yml,yaml}\" \"stryker.conf.mjs\" \"vitest.config.ts\" \"vitest.mutation.config.ts\"",
     "format:staged": "node scripts/run-staged-checks.mjs",
     "docker:ssh-fixture:up": "node scripts/docker-ssh-fixture.mjs up",
+    "docker:ssh-fixture:verify": "node scripts/docker-ssh-fixture.mjs verify",
+    "docker:ssh-fixture:diagnostics": "node scripts/docker-ssh-fixture.mjs diagnostics",
     "docker:ssh-fixture:down": "node scripts/docker-ssh-fixture.mjs down",
+    "check:fixture-results": "node scripts/check-fixture-test-results.mjs",
     "e2e:docker": "node scripts/docker-ssh-fixture.mjs run e2e",
     "integration:docker": "node scripts/docker-ssh-fixture.mjs run integration",
     "docs": "pnpm exec typedoc --options typedoc.json",
     "docs:check": "pnpm exec typedoc --options typedoc.json --treatWarningsAsErrors",
     "start:http": "node dist/render-http.js",
+    "start:chatgpt": "node scripts/start-chatgpt-http.mjs",
     "sync-version": "node scripts/sync-version.mjs",
     "validate:mcp-metadata": "node scripts/validate-mcp-metadata.mjs",
     "validate:mcp-registry": "node scripts/check-mcp-registry-record.mjs",
@@ -136,16 +153,18 @@
     "release:state": "node scripts/release-state.mjs",
     "check:npm-name": "node scripts/check-npm-name.mjs ssh-mcp-pro",
     "audit": "pnpm audit --audit-level moderate",
+    "audit:packed": "node scripts/check-packed-consumer-audit.mjs",
     "licenses:check": "node scripts/check-licenses.mjs",
     "reuse:lint": "reuse lint",
     "pack:check": "node scripts/check-package-contents.mjs",
     "pack:install-smoke": "node scripts/check-package-install-smoke.mjs",
+    "pack:lint": "publint --strict=false",
     "check:knip": "knip -c knip.jsonc --reporter compact || true",
     "check:circular": "depcruise src --config .dependency-cruiser.mjs || true",
     "check:module-size": "node scripts/check-module-size.mjs",
     "check:maintainability": "pnpm run check:module-size && pnpm run check:circular && pnpm run check:knip",
     "check:quality": "pnpm run format:check && pnpm run check:doc-language && pnpm run check:package-scripts && pnpm run check:rulesets && pnpm run verify:actions-runtime && pnpm run lint && pnpm run typecheck && pnpm run audit && pnpm run licenses:check",
-    "check:package": "pnpm run build && pnpm run sync-version -- --check && pnpm run validate:mcp-metadata && pnpm run validate:chatgpt-app && pnpm run validate:claude-connector && pnpm run docs:check && pnpm run pack:check && pnpm run pack:install-smoke",
+    "check:package": "pnpm run build && pnpm run sync-version -- --check && pnpm run validate:mcp-metadata && pnpm run validate:chatgpt-app && pnpm run validate:claude-connector && pnpm run docs:check && pnpm run pack:check && pnpm run pack:install-smoke && pnpm run audit:packed",
     "check:push": "pnpm run format:check && pnpm run lint && pnpm run typecheck && pnpm test",
     "check": "pnpm run check:quality && pnpm run test:coverage && pnpm run check:package",
     "hook:pre-commit": "pnpm run format:staged",

package/registry/ssh-mcp-pro/mcp.json

@@ -2,7 +2,7 @@
   "name": "ssh-mcp-pro",
   "display_name": "ssh-mcp-pro",
   "description": "Secure MCP SSH automation server with policy controls, resources, prompts, stdio, and HTTP.",
-  "version": "1.1.4",
+  "version": "1.2.1",
   "author": "Osman Aslan",
   "license": "MIT",
   "runtime": "node",

package/server.json

@@ -7,13 +7,13 @@
     "url": "https://github.com/oaslananka/ssh-mcp-pro",
     "source": "github"
   },
-  "version": "1.1.4",
+  "version": "1.2.1",
   "packages": [
     {
       "registryType": "npm",
       "registryBaseUrl": "https://registry.npmjs.org",
       "identifier": "ssh-mcp-pro",
-      "version": "1.1.4",
+      "version": "1.2.1",
       "transport": {
         "type": "stdio"
       }
@@ -22,7 +22,7 @@
       "registryType": "npm",
       "registryBaseUrl": "https://registry.npmjs.org",
       "identifier": "ssh-mcp-pro",
-      "version": "1.1.4",
+      "version": "1.2.1",
       "runtimeHint": "npx",
       "transport": {
         "type": "streamable-http",