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

145 lines
4.8 KiB
Markdown

---
name: security-tools
description: "Class-level skill consolidating security-related utilities such as 1Password vault management and its CLI setup."
version: 1.0.0
tags: [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:
```bash
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)
```bash
# 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:
```bash
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.
```bash
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:
```bash
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
```bash
# 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`.