Managed SSH Keypair

Each account in the Crafting system — whether a User or a Service Account — has a default SSH keypair managed by the Crafting system. The keypair is secured in a vault service, making it impossible to access the private key directly. It can only be used via specific internal sign/verify and encrypt/decrypt APIs.

When the sandbox owner is working inside a Crafting workspace, the SSH keypair is automatically loaded into the SSH agent that is seamlessly hosted within the workspace. This allows the keypair to be used transparently for authenticating to external services such as git repositories, without any manual configuration.

Accessing the Public Key

To view the public key, use the Web UI or the CLI:

cs secret show --user default-ssh-0

Alternatively, access the file directly inside a workspace:

/run/sandbox/fs/secrets/owner/default-ssh-0

In most cases, when a new user is onboarded to the Crafting system, this public key should be registered in their account on the git repository provider (e.g. GitHub) to enable pull/push access using the SSH protocol.

Rotating the Keypair

When needed, the keypair can be rotated from the Web UI, or using:

cs secret regenerate-sshkey

After rotating, remember to update the registered public key in any external services that use it (e.g. GitHub deploy keys, SSH authorized keys files).

The SSH Agent

The Crafting workspace includes a built-in SSH agent that automatically loads the managed keypair. The agent socket is available at /run/sandbox/svc/sshagent.sock.

The environment variable SSH_AUTH_SOCK must be set to this path for SSH clients to use the agent. This is configured correctly by default. If the value of SSH_AUTH_SOCK has been overridden to a different path, the managed keypair may no longer be accessible.

Troubleshooting SSH access denied errors: The first thing to check when debugging SSH public key authentication failures is the value of SSH_AUTH_SOCK. Verify it is set to /run/sandbox/svc/sshagent.sock.

See Also