Managing SSH keys

SSH keys in CoreLatency are used during server provisioning to place your public key into the server's authorized_keys file. This allows you to log in securely as soon as the build completes without relying on password-based access during deployment.

What we store

You provide the public key only.

CoreLatency does not take custody of your private key, cannot reconstruct it, and does not store it as part of this workflow. The trust model is intentionally straightforward: you keep the private half, and we deploy the public half to the server being built.

How keys are used

When a server is provisioned with an SSH key selected, the public key is written to the operating system so you can authenticate immediately after the server comes online.

This is the standard and recommended access model for provisioned infrastructure because it provides strong authentication without embedding passwords into the build process.

Password authentication

CoreLatency does not support password authentication as part of the default provisioning flow. This is a deliberate security choice.

If you have a specific operational reason to use password-based login, you can enable it yourself after the server has been built. If needed, you can also access the machine through the console using the root password shown on the deployed server page.

Operational guidance

For most environments, the recommended approach is:

• upload a trusted public SSH key to the console
• select that key during server provisioning
• retain private-key custody within your own security controls

This keeps initial access fast, auditable, and aligned with normal infrastructure security practice.