Authorized Key
The key you already have
The first time an engine starts it creates a key pair for itself: the private half lands at ~/.dxflow/private-key.pem (mode 600) and the public half is authorized with MASTER. Sign in with that file and there is nothing to generate or register.
Issue additional keys when you want separate identities or narrower permissions — a per-environment key, or one scoped to WORKFLOW for CI.
Generating another key
Use either the built-in CLI or ssh-keygen. Each produces a private key (keep secure) and a public key (for registration).
Method 1: dxflow CLI
dxflow key generate [NAME]
[NAME] is optional and defaults to rsa. The command writes two files in the current directory: [NAME].pem (private) and [NAME].pub (public).
Method 2: ssh-keygen
ssh-keygen -t rsa -b 2048 -m PEM -C "<your_email@example.com>"
-t rsa sets the key type, -b 2048 the length, -m PEM the private-key format, and -C an optional comment. This writes id_rsa (private) and id_rsa.pub (public).
-m PEM is required. dxflow reads PKCS#1/PKCS#8 PEM private keys, not OpenSSH's default -----BEGIN OPENSSH PRIVATE KEY----- format. Without it the public key still registers, but the private key won't parse at authentication. To fix an existing key, convert in place: ssh-keygen -p -m PEM -f <private-key>.Key management
dxflow key register <public-key-path> # register a public key
dxflow key register <public-key-path> --permissions WORKFLOW # scope what it can do
dxflow key list # list registered keys (shows IDENTITY)
dxflow key unregister <identity> # remove a key by its IDENTITY
Registered without --permissions, a key receives SHELL, ARTIFACT, RUNTIME, WORKFLOW, and AGENT. See the permission model.
Authentication process
dxflow uses challenge-response: the server sends a one-time challenge, the client signs it with the private key (so the key is never sent), and the server verifies the signature and issues a session token. The token is stored in your profile config.