SSH key enrollment

What it’s for

Proxploy generates one dedicated Ed25519 keypair per host you enroll for SSH. It’s used for exactly one thing: running App Store install, update, and migration scripts on that node, the same scripts community-script installers have always run as root, just triggered from Proxploy instead of typed by hand. There is no console path and no general-purpose command runner behind this key; it exists for that one job and nothing else.

The private key is generated in-process, encrypted at rest the moment it’s created, and never written to disk in plaintext or leaves the app process.

Why it’s optional

Adding a host at all is optional (see Getting started), and authorizing SSH for a host you did add is optional too. Everything in Proxploy except installing, updating, or migrating apps works with just the API token from The minimal-privilege API token. Monitoring, lifecycle actions, consoles, backups, and snapshots all go through the Proxmox API, not SSH. Skip this step if you only want those.

Authorizing the key

When a host needs SSH, the wizard shows you a line to add yourself:

echo '<the public key>' >> /root/.ssh/authorized_keys

Add it in a node shell you already have. Proxploy never installs its own key for you. The wizard’s consent text says plainly what you’re granting:

This key gives Proxploy a root shell on the node, used only for App Store install/update/migration scripts, exactly as if you ran them yourself as root on the node. Every use is audit-logged and its full output archived.

Once the line is added, click Verify access. Proxploy confirms it can now reach the node over SSH before letting you continue.

If verification fails

Two different messages mean two different things:

• “Not authorized yet”: the most common case. Double-check the line was added to /root/.ssh/authorized_keys on the node and saved.
• “The node’s SSH host key changed since Proxploy first saw it. Stop and investigate.”: Proxploy pins each node’s host key on first contact (trust-on-first-use) and hard-fails rather than silently accepting a changed one. This is a security event, not a retry-until-it-works situation: confirm independently that the node’s host key legitimately changed (a reinstall, a restored VM) before re-verifying.