Managing OpenClaw and Hermes VPS SSH access with CertLocker

The messy part of running self-hosted infrastructure is not always Kubernetes, Terraform, or the application code. Sometimes it is simpler and more dangerous: a small fleet of public VPS machines that are important enough to need tight access control, but distributed enough that they never quite fit the neat enterprise model.

That is common with OpenClaw and Hermes-style deployments. You may have a gateway node on OVHcloud, an API node on Hetzner, a runner on OneProvider, and a few utility machines added during incidents or experiments. Each provider has its own console, metadata model, billing account, image defaults, and SSH key handling. The servers are real production or near-production systems, but access often starts as a PEM file on someone's laptop.

CertLocker does not need to pretend those providers are the same cloud. It gives you a provider-neutral trust layer over the access model. The VPS is a host. The gateway private key is a secret. The access grant is a token. The routing path is a bastion. The evidence is an audit event.

The problem: public VPS access becomes tribal knowledge

VPS fleets usually grow sideways. Someone adds a server because a workload needs more memory. Someone else moves a runner to a cheaper provider. A third person creates a gateway machine because direct SSH to every node is becoming uncomfortable.

The access model rarely grows with the same care. Common failure modes look like this:

• A single provider-level SSH key is reused across every instance.
• Gateway PEM files are copied through chat, password managers, or old deployment folders.
• Hostnames encode provider and workload, but nothing enforces the access boundary.
• Contractors get access to one node and accidentally inherit access to the whole fleet.
• Auditing requires checking provider consoles, SSH logs, shell history, and deployment tickets.

That model is tolerable for a weekend lab. It is not good enough for infrastructure that runs customer-facing workloads, automation agents, or operational control planes.

The CertLocker model: treat VPS machines as governed hosts

CertLocker's host inventory gives the team one place to describe the machines that matter, regardless of provider. In the demo screenshot, the host list contains:

• openclaw-ovh-gw-01 as an OpenClaw gateway VPS hosted on OVHcloud.
• openclaw-hetzner-api-01 as an OpenClaw API VPS hosted on Hetzner.
• hermes-oneprovider-runner-01 as a Hermes automation runner hosted on OneProvider.

Those names are synthetic, but the structure is intentional. Provider, workload, and role are visible in the name and in the group tags. The host record stores the address, SSH port, group ownership, linked gateway secret, and optional bastion relationship.

host: openclaw-hetzner-api-01
provider group: hetzner
workload group: openclaw
access group: public-vps
port: 22
secret: OpenClaw VPS Gateway Key
bastion: vps-edge-bastion

The important point is not the exact naming scheme. The important point is that SSH access stops being a pile of provider-specific notes and becomes a set of governed assets.

Gateway keys belong in the secrets layer

Most small fleets start with a gateway key because it is the easiest way to avoid logging into every target directly. That gateway key is powerful. If it leaks, the attacker may not need the cloud console. They only need the key and enough network reachability.

CertLocker stores that material as a PEM secret with groups, usage references, lifecycle actions, and audit history. The screenshot below shows an OpenClaw gateway PEM secret linked to the host and token that use it.

This changes the workflow. Instead of asking "who has the gateway key?", the team can ask better questions:

• Which host records use this key?
• Which tokens can reach hosts through this key?
• Which groups can see or modify the secret?
• When was the key rotated?
• What access events happened after the rotation?

Gateway keys still need normal operational care. You still rotate them, limit who can read them, and avoid copying them into build logs. CertLocker makes that care visible and repeatable.

Short-lived SSH tokens are better than shared provider keys

A provider key answers the wrong question. It says, "can this private key log into this instance?" It does not say who is using it, why they need it, how long the access should last, or whether they should reach every server that key has ever touched.

A CertLocker SSH token can be scoped to groups such as openclaw and public-vps, given a short duration, linked to the gateway secret, and routed through a bastion. In the demo, OpenClaw VPS SSH lasts four hours and reaches only the OpenClaw VPS hosts in scope.

The operational difference is large:

shared provider key:
  broad, long-lived, copied, hard to audit

CertLocker SSH token:
  scoped, time-bound, user-verifiable, tied to hosts and audit events

This is especially useful for internet-hosted workloads because the network boundary is already more exposed. A VPS with a public address deserves stricter credential handling, not looser handling because it is "just a small server."

Bastions give the fleet a controlled access path

A VPS bastion does not have to be a massive enterprise jump host. It can be a small gateway that centralizes the SSH route for a workload group. What matters is that the gateway is managed as an asset, attached to hosts, and governed by token policy.

CertLocker's bastion model lets the team represent that access path directly. The host points at a bastion. The token points at the hosts and gateway material. The user connects through CertLocker using the token-style SSH username. The bastion validates the token, resolves the requested host, handles the interactive authentication flow when needed, and opens the target session.

For operators, that can still look like normal SSH:

Host openclaw-ovh
    HostName ssh-gateway.public-vps.example
    Port 2222
    User <openclaw-token>@openclaw-ovh-gw-01
    PreferredAuthentications keyboard-interactive
    KbdInteractiveAuthentication yes
    PubkeyAuthentication no

The operator gets a familiar command. The security team gets token validation, 2FA-capable keyboard-interactive flow, scoped host resolution, and auditability.

Where CertLocker should plug into OpenClaw and Hermes

The practical integration is not "make OpenClaw store secrets." OpenClaw and Hermes should stay focused on agent runtime, messaging, tools, workflows, and command execution. CertLocker should become the trust layer those runtimes ask for credentials, short-lived SSH, rotation, and evidence.

That matters because current OpenClaw guidance is built around fast server setup, Docker, persistent state, and remote access. The OpenClaw Linux server guide frames the VPS as the place where the gateway owns state and workspace. The Hetzner guide shows the same pattern with Docker, durable ~/.openclaw state, and gateway access through SSH port forwarding or a carefully controlled exposed port. The remote access guide also treats SSH tunneling as the universal fallback. Hermes migration has the same operational shape: OpenClaw can import Hermes configuration, memory, skills, and supported credentials, but someone still has to maintain Linux, Docker, gateway restarts, provider keys, backups, and updates.

CertLocker fits exactly around that operational boundary:

• Provider bootstrap secrets. Hetzner, OVHcloud, OneProvider, DNS, model provider, webhook, and backup credentials can be stored as named CertLocker secrets rather than pasted into setup notes.
• Gateway SSH keys. OpenClaw and Hermes VPS keys can be stored as PEM secrets, linked to hosts, and rotated without asking which laptop still has the original key.
• Member-bound shell access. Human operators can use short-lived SSH tokens with email or TOTP 2FA before a native shell or browser terminal opens.
• Agent-run maintenance. If an AI assistant is asked to patch, restart, or inspect a VPS, it can be given a constrained CertLocker access path instead of a raw provider key.
• Evidence for agent activity. Secret reads, rotations, token changes, host onboarding, and SSH sessions become reviewable audit events.

This is the right division of responsibility. OpenClaw or Hermes can request "the openclaw/ovh/gateway credential" or "a two-hour shell route to openclaw-ovh-gw-01." CertLocker decides who can retrieve it, whether 2FA is required, whether the token is still valid, and what audit record is written.

Make the setup easy enough for an AI to run

A useful integration has to survive the way teams will actually deploy these systems: someone will ask an AI assistant to set up a VPS. The prompt should not hand the assistant permanent secrets in chat. It should hand the assistant a small manifest of CertLocker asset names and let CertLocker enforce the dangerous parts.

certlocker:
  account: linx
  workload: openclaw
  environment: public-vps
  groups:
    - openclaw
    - public-vps
    - ovhcloud

secrets:
  - name: OpenClaw VPS Gateway Key
    type: PEM
    rotate: on-demand
  - name: OpenClaw Provider API Token
    type: SECRET
    rotate: 30d
  - name: OpenClaw Backup Bucket Credentials
    type: SECRET
    rotate: 30d

hosts:
  - name: openclaw-ovh-gw-01
    provider: ovhcloud
    port: 22
    secret: OpenClaw VPS Gateway Key

tokens:
  - name: OpenClaw VPS SSH
    type: SSH
    duration: 4h
    user: [email protected]
    require_2fa: true
    hosts:
      - openclaw-ovh-gw-01

That manifest is intentionally plain. A human can read it, and an AI assistant can apply it through an API, CLI, or guided browser workflow. The assistant does not need to know the private key value after creation. It only needs the CertLocker reference, the host binding, and the token policy.

Secret retrieval and rotation should be explicit

There are three useful retrieval patterns for OpenClaw and Hermes fleets:

1. Setup-time injection. CertLocker supplies a secret during installation, such as a model provider token or webhook signing key, and records that the value was retrieved for setup.
2. Runtime lookup. The agent runtime receives a short-lived CertLocker token and resolves a secret only when a workflow needs it, avoiding long-lived values in local files where possible.
3. SSH access brokering. The agent or human operator does not receive the gateway key at all; it receives a short-lived SSH path through CertLocker.

Rotation should follow the same principle. OpenClaw already has a secrets CLI for auditing plaintext residues, SecretRefs, and unresolved references. CertLocker can complement that by owning the external secret value and rotation record: old version, new version, affected hosts or tokens, actor, time, and follow-up SSH sessions. If an AI assistant rotates a gateway key, the next review should show that as a normal security event, not as a mystery change in a VPS filesystem.

A concrete CertLocker integration contract

The most useful OpenClaw integration would be small and boring: a CertLocker-backed SecretRef provider plus a CertLocker SSH broker. That keeps the agent runtime simple while moving the dangerous access decisions into a system built for secrets, expiry, 2FA, and audit.

In practical terms, the contract can look like this:

• OpenClaw config stores references. Model keys, gateway tokens, webhook secrets, backup credentials, and provider API tokens point at CertLocker secret names or IDs.
• CertLocker resolves the value. Retrieval requires a scoped token, group policy, optional CIDR policy, and an audit event.
• OpenClaw reloads after rotation. After CertLocker rotates a referenced secret, OpenClaw runs its secrets reload path so the runtime snapshot updates without spreading plaintext.
• Shell access is brokered separately. Human and AI-assisted maintenance use short-lived SSH tokens, not the same raw PEM secret used by the host.
• Audit joins the story together. A rotation event, secret retrieval, token issue, 2FA challenge, and SSH session are all reviewable in one CertLocker trail.

OpenClaw / Hermes runtime:
  needs: "openclaw/provider/openai"
  asks: CertLocker SecretRef provider
  receives: value only if policy allows

Operator or AI maintenance:
  needs: "shell to openclaw-ovh-gw-01 for 2 hours"
  asks: CertLocker SSH token
  receives: browser/native SSH route with member 2FA

Rotation:
  CertLocker rotates secret
  OpenClaw runs secrets reload
  audit links rotation -> reload -> subsequent access

This is where CertLocker matters most for AI-assisted setup. The assistant can be told to "configure OpenClaw with certlocker://openclaw/provider/openai" or "request a two-hour SSH route for openclaw-ovh-gw-01." It should not be given the actual provider key, gateway PEM, or long-lived VPS credential in the prompt.

How an AI-assisted setup should run

If someone asks an AI assistant to deploy or maintain OpenClaw on a VPS, the prompt should give it a narrow playbook:

1. Create or select CertLocker secrets for provider keys, gateway tokens, backup credentials, and SSH PEM material.
2. Create CertLocker host records for each VPS and link the right gateway secret.
3. Create a short-lived, member-bound SSH token for the setup window.
4. Use the browser terminal or native SSH alias to run the installation.
5. Configure OpenClaw or Hermes with secret references, not plaintext values.
6. After rotation, trigger OpenClaw secrets reload and check CertLocker audit.

That gives the AI enough authority to be useful without turning the chat transcript into an accidental credential store. It also gives the human reviewer a clean question to answer later: which CertLocker references were used, who approved the shell route, which 2FA challenge was completed, and what changed on the VPS?

Audit evidence turns provider sprawl into reviewable access

Provider consoles are not designed to answer every access question across a mixed VPS estate. They can show instance events, key injection, and sometimes login-related metadata, but they do not give you a provider-neutral access story across OVHcloud, Hetzner, OneProvider, and your own bastion path.

CertLocker's audit stream gives the access model one evidence plane. In the demo, audit events show the OpenClaw SSH session, a Hermes gateway key rotation, and a host being added to the public VPS scope.

During an access review, that lets you answer the questions that matter:

• Which public VPS hosts are managed by CertLocker?
• Which gateway secrets back those hosts?
• Which short-lived tokens can reach them?
• Who opened SSH access and when?
• What changed around the same time?

That is far cleaner than reconstructing a timeline from three provider dashboards and a collection of terminal history.

A practical rollout for OpenClaw and Hermes VPS fleets

You do not need to move every server at once. A pragmatic rollout looks like this:

1. Inventory the public hosts. Start with the nodes that matter: gateways, APIs, runners, deployment targets, and recovery boxes.
2. Create clear groups. Use groups such as openclaw, hermes, public-vps, ovhcloud, hetzner, and oneprovider.
3. Store gateway PEMs as secrets. Put provider or gateway keys into CertLocker as PEM secrets, grouped by workload and environment.
4. Attach secrets to hosts. Each host should show which credential path is used for access.
5. Create short-lived SSH tokens. Scope tokens by host groups and start with short durations, especially for production-like systems.
6. Use SSH aliases for operators. Keep the command-line experience familiar while routing through CertLocker.
7. Review audit evidence after the first week. Confirm that access, rotation, and host changes are visible enough for real incident review.

The goal is not to hide provider differences. The goal is to stop provider differences from becoming access-control differences.

Where this fits with the rest of CertLocker

This VPS access pattern sits beside the other CertLocker workflows:

• Short-lived SSH access with 2FA and audit trails explains the token and 2FA path.
• Ansible deployment hardening shows how gateway tokens and PEM sync fit deployment automation.
• Replacing Ansible Vault sprawl explains why runtime lookup beats committed secret sprawl.
• CertLocker SSH Access covers the product surface for scoped SSH access.
• OpenClaw Linux server and VPS guide
• OpenClaw guide for migrating from Hermes

For OpenClaw and Hermes-style workloads, the value is simple: the servers can stay where they are, across the providers that make sense for cost and locality, while access control moves into one operational trust layer.

That is the practical fit for CertLocker. It does not replace the VPS provider. It replaces the scattered access model around those VPS machines.