Relationships
#917 Add SSH host public key collection for host certificate workflows
Opened by evrardjp · 7/2/2026· Shipped 7/2/2026
Feature request
Please add a first-class SSH host public key collection capability to the SSH extension.
Use case
I am wiring a lab to use OpenSSH host certificates:
- A VM inventory model emits desired host identity, including host certificate principals and paths.
- The SSH extension connects to each VM through bootstrap SSH and collects the VM's public host key, usually
/etc/ssh/ssh_host_ed25519_key.pub. - A separate SSH CA model signs that public key with the VM's desired principals.
- A cfgmgmt/deploy step installs the resulting
HostCertificateand sshd config on the VM.
The SSH extension should own step 2: observing host public keys from reachable SSH targets. It should not sign certificates and should not own CA state.
Desired method
A method on the SSH host model such as:
collect-host-public-keyInputs:
host: 192.168.164.10
user: admin
port: 22
identityFile: ~/.ssh/id_ed25519
hostKeyPath: /etc/ssh/ssh_host_ed25519_key.pubThe exact field names should match the existing SSH extension conventions. hostKeyPath should default to /etc/ssh/ssh_host_ed25519_key.pub.
Output data should include:
{
"name": "bao",
"host": "192.168.164.10",
"user": "admin",
"hostKeyPath": "/etc/ssh/ssh_host_ed25519_key.pub",
"publicKey": "ssh-ed25519 AAAA...",
"algorithm": "ssh-ed25519",
"fingerprint": "SHA256:...",
"observedAt": "..."
}Validation and behavior
- Read only the public key from the remote host. Never fetch private host keys.
- Validate that the returned content is a single OpenSSH public key line.
- Compute and emit an OpenSSH-style fingerprint.
- Fail clearly if the file is missing, unreadable, empty, or not a valid public key.
- Keep the method independent of certificate signing and CA management.
Optional fan-out variant
A batch method would also be useful, but is not required if the extension supports clean per-host model instances:
collect-host-public-keysInputs:
hosts:
- name: bao
host: 192.168.164.10
user: admin
hostKeyPath: /etc/ssh/ssh_host_ed25519_key.pub
- name: gitea
host: 192.168.164.12
user: admin
hostKeyPath: /etc/ssh/ssh_host_ed25519_key.pubOutput could be one data resource per host, with partial failure details per host.
Why this belongs in SSH
This is a generic SSH inventory/discovery operation: connect to a host and read/validate its public SSH host key. The CA extension should only sign explicit public keys and principals. VM inventory models should only publish desired identity and connection data. The SSH extension is the natural place to observe remote host key material.
Larger workflow this enables
- VM inventory emits
sshHostCertificate.ca,sshHostCertificate.principals,hostKeyPath, andhostCertificatePath. - SSH extension collects
/etc/ssh/ssh_host_ed25519_key.pubover bootstrap SSH. - SSH CA extension runs
issue-host-certificatewith workflow concurrency set to 1. - cfgmgmt deploys
/etc/ssh/ssh_host_ed25519_key-cert.puband an sshd drop-in containingHostCertificate.
Upstream repository: https://github.com/swamp-club/swamp-extensions
Environment
- Extension:
@swamp/ssh@2026.06.04.2 - swamp:
20260630.112427.0-sha.0e5078e9 - OS:
linux(x86_64) - Deno:
2.8.3 - Shell:
/bin/bash
Shipped
Click a lifecycle step above to view its details.
evrardjp commented 7/2/2026, 4:39:48 PM
I am not 100% convinced it belongs here. I am not even convinced you need to connect with identify file... (ssh-keyscan does not need it afaik).
It's just the agent being overly confident about this. Maybe tell me what's the best approach to take here, or what others have done?
Sign in to post a ripple.