返回全部 Skills

sshepherd

Zero-knowledge SSH ops CLI — server health checks, docker/systemd control, log tailing, Postgres introspection, and declarative deploys, without ever exposing credentials to the agent.

0

下载量

AI SkillHub 能力展示图

安装方式

命令行安装

在项目根目录执行以下命令,完成 Skill 安装。

npx bzskills add sickn33/antigravity-awesome-skills --skill sshepherd

skill.md

name: sshepherd
description: Zero-knowledge SSH ops CLI — server health checks, docker/systemd control, log tailing, Postgres introspection, and declarative deploys, without ever exposing credentials to the agent.
category: devops
risk: critical
source: community
source_repo: Antheurus/sshepherd
source_type: community
date_added: "2026-07-15"
author: Antheurus
tags: [ssh, devops, cli, server-ops, postgres, deploy, zero-knowledge]
tools: [claude, cursor, gemini, codex]
license: "MIT"
license_source: "https://github.com/Antheurus/sshepherd/blob/main/LICENSE"

sshepherd

Overview

sshepherd is a compiled Bun/TypeScript CLI that lets an agent operate a real remote server over SSH — health checks, docker/systemd service control, log tailing, config file edits, read-only Postgres introspection, and declarative deploys — without ever seeing a password, private key, hostname, username, or port. Every operation shells out to the system ssh binary through a single transport path and returns the same typed Envelope<T> (ok, alias, data, error), never a raw terminal dump. The agent passes only a *name* — an ssh alias, a Postgres target, or a deploy recipe — that resolves entirely outside the process.

When to Use This Skill

  • Use when you need to check a remote server's health (disk, memory, CPU, ports, OOM history) without handing the agent SSH credentials.
  • Use when working with remote docker or systemd services — listing, inspecting, or restarting them — or tailing their logs.
  • Use when the user asks to read or edit a remote config file, run a declarative deploy from a named recipe, introspect a remote Postgres database read-only, or audit SSH/security posture on a box.

How It Works

Step 1: Declare targets once, outside any prompt

Every connection detail is declared ahead of time and never appears on the command line: ssh aliases in ~/.ssh/config, Postgres targets in ~/.config/sshepherd/targets.toml, deploy recipes in recipe TOML files. OpenSSH resolves the real HostName/User/Port/IdentityFile internally.

Step 2: Invoke a group + action by name

sshepherd <group> <action> [positionals...] [--flag value]

Nine command groups — hosts, check, logs, services, deploy, config, db, files, security — 52 ops total. Output is JSON to stdout by default; add --pretty for a human-readable table/key-value view. The response only ever echoes back the alias it was given — there is no host/user/port/ip field anywhere in the response type, structurally.

Step 3: Discover the command surface

./dist/sshepherd --help                 # list groups
./dist/sshepherd check --help           # list actions + flags for one group

Examples

Example 1: Server health overview

./dist/sshepherd check overview lms-server

Returns a JSON envelope with disk, memory, CPU, listening ports, and OOM history for the host behind the lms-server alias — the agent never learns the host's address.

Example 2: Restart a docker service and tail its logs

./dist/sshepherd services restart lms-server --name api
./dist/sshepherd logs tail lms-server --name api --lines 100

Example 3: Read-only Postgres introspection

./dist/sshepherd db tables prod

prod is a pg-target name that resolves to *how* to reach psql on a host — never a database password. psql runs inside the target container, authenticated by peer/trust/.pgpass already on the remote.

Best Practices

  • ✅ Declare every alias/target/recipe ahead of time in ~/.ssh/config / targets.toml / recipe TOML — never inline connection details.
  • ✅ Pass only names (alias, pg-target, recipe) to the CLI; let OpenSSH own authentication.
  • ✅ Use --pretty for human review and default JSON output for machine parsing.
  • ❌ Don't try to inject a hostname, user, port, or password into a command — the CLI has no field for them.
  • ❌ Don't reach for the ssh2 npm library or hand-rolled SSH; the whole point is delegating to the trusted system ssh binary.

Limitations

  • This skill does not replace environment-specific validation, testing, or expert review.
  • Stop and ask for clarification if required inputs, permissions, or safety boundaries are missing.
  • Requires the system OpenSSH client and pre-declared aliases/targets/recipes; it cannot connect to a host that has not been configured outside the agent.
  • Postgres access is read-only introspection by design.

Security & Safety Notes

  • Zero-knowledge credential model: the agent never sees a password, private key, hostname, username, or port. It only ever passes an ssh alias, a pg-target name, or a recipe name; the real connection tuple is resolved by OpenSSH outside the process, and every response echoes back only the alias.
  • Never reads private key material. Authentication happens entirely inside OpenSSH's own trusted code path.
  • Confirmation gate on mutations: destructive/mutating actions (service restart, config write, deploy) require an explicit --yes confirm flag.
  • Human-only credential entry: the separate setup ssh-alias install action opens a one-shot local browser form that only a human can type a password into — the agent can trigger and wait on it but never sees, logs, or relays the password.
  • Environment expectation: run against hosts you are authorized to operate.

Common Pitfalls

  • Problem: Trying to pass a hostname or password directly to a command.

Solution: Register the target first (setup ssh-alias register / setup db-target), then reference it only by name.

  • Problem: A mutating action returns without doing anything.

Solution: Add the --yes confirm flag — mutations are gated by design.

Related Skills

  • @devops-automation - When you need broader CI/CD or infrastructure-as-code automation beyond SSH ops.