hermes-skills/security/security-tools/SKILL.md

name, description, version, tags

name	description	version	tags
security-tools	Class-level skill consolidating security-related utilities such as 1Password vault management and its CLI setup.	1.0.0	security 1password vault

Overview

This umbrella skill merges:

• 1password-vault-management
• op-cli-setup

It provides unified instructions, reference docs, and templates for managing secrets via the 1Password CLI.

Using 1Password CLI from Hermes

Hermes is already configured with OP_SERVICE_ACCOUNT_TOKEN in the shell environment. No additional op signin is required. Verify with:

op account list   # should show the vault
op vault list     # lists accessible vaults

Service-account tokens can only see vaults explicitly granted to the integration.

Storing SSH Keys in 1Password

CRITICAL: SSH Key Category is Buggy

op item template get "SSH Key" returns a template with a private_key field (type SSHKEY), but op item create silently discards the private_key value. The item is created without the private key. Always verify with op item get ID --reveal.

Store SSH Key in 1Password — SECURE_NOTE vs LOGIN

There are two usable patterns depending on whether the user needs visibility in the 1Password app:

SECURE_NOTE (automation focus)

# Build template with CONCEALED field 'private key'
cat << 'EOF' > /tmp/op_template.json
{
  "title": "hermes-agent Proxmox SSH Key",
  "category": "SECURE_NOTE",
  "fields": [
    {
      "id": "notesPlain",
      "type": "STRING",
      "purpose": "NOTES",
      "label": "notesPlain",
      "value": "Public key:\nssh-ed25519 AAAAC3N... hermes-agent@proxmox\n\nNodes:\n10.0.20.10 proxmox1 ..."
    },
    {
      "id": "private_key",
      "type": "CONCEALED",
      "label": "private key",
      "value": "-----BEGIN OPENSSH PRIVATE KEY-----\n..."
    }
  ]
}
EOF
cat /tmp/op_template.json | op item create - --vault Hermes

Retrieval:

op read 'op://Hermes/hermes-agent Proxmox SSH Key/private key'

Pitfall: 1Password app may hide or bury SECURE_NOTE items in a "Documents" view. If user says "I can't see it," convert to LOGIN instead.

LOGIN (user-visible, recommended for interactive use)

Use category: LOGIN with purpose: PASSWORD on the private key field. This renders under the Logins tab in all 1Password apps.

cat << 'EOF' > /tmp/op_template.json
{
  "title": "hermes-agent Proxmox SSH Key",
  "category": "LOGIN",
  "fields": [
    {
      "id": "username",
      "type": "STRING",
      "purpose": "USERNAME",
      "label": "username",
      "value": "root"
    },
    {
      "id": "password",
      "type": "CONCEALED",
      "purpose": "PASSWORD",
      "label": "password",
      "value": "-----BEGIN OPENSSH PRIVATE KEY-----\n..."
    },
    {
      "id": "notesPlain",
      "type": "STRING",
      "purpose": "NOTES",
      "label": "notesPlain",
      "value": "Public key:\nssh-ed25519 AAAAC3N... hermes-agent@proxmox\n\nNodes:\n10.0.20.10 proxmox1 ..."
    }
  ]
}
EOF
cat /tmp/op_template.json | op item create - --vault Hermes --tags infrastructure,ssh

Retrieval:

op read 'op://Hermes/hermes-agent Proxmox SSH Key/password'

Which to Choose

• User will access interactively in the 1Password app → LOGIN
• Pure automation / agent-only use → SECURE_NOTE

Retrieval

# Read private key
op read 'op://Hermes/hermes-agent Proxmox SSH Key/private key'

# Full item (with reveal)
op item get "hermes-agent Proxmox SSH Key" --vault Hermes --reveal

References

• references/1password-vault.md
• references/op-cli-setup.md
• references/ssh-key-vault-storage.md

Pitfalls

op item create silently discards SSH_KEY.private_key field

op item template get "SSH Key" returns a private_key field (type SSHKEY), but op item create silently drops the value. The item is created but the private key is empty. Always verify with op item get ID --reveal immediately after creation. If the field is missing, recreate as LOGIN or SECURE_NOTE.

Service Account Token limits

OP_SERVICE_ACCOUNT_TOKEN can see only vaults explicitly granted. If op vault list returns nothing, the token lacks vault access — not a login issue.

SSH host key caching and BatchMode

When deploying keys to many hosts with -o StrictHostKeyChecking=no, the first connection adds to ~/.ssh/known_hosts. Subsequent BatchMode=yes calls may still fail with Host key verification failed. if known_hosts has conflicting entries. Use ssh-keyscan -H IP >> ~/.ssh/known_hosts proactively, or force StrictHostKeyChecking=accept-new on verification SSH calls.

Duplicate authorized_keys entries

Running key deployment twice appends the same key again. Always deduplicate: awk '!seen[$0]++' ~/.ssh/authorized_keys > /tmp/ak && mv /tmp/ak ~/.ssh/authorized_keys.