EC Key Compatibility — Named Curves vs Explicit Parameters
Note before reading. If you're using a resource that uses SSH auth, the following will not retroactively affect anything. If a key has been working it will continue to work.
The official Cycle documentation suggests generating SSH keys using the following pattern.
ssh-keygen -t ecdsa -b 256 -m PEM -f your-filename.pem
This pattern will generate an ecdsa
key, which we've recently found can cause compatibility issues with the Golang x509
package IF the ssh backend is using LibreSSL instead of OpenSSL.
LibreSSL is the default library used by ssh/ssh-keygen on Mac.
The Issue
- OpenSSL-based keygens (most Linux) use named curves (like prime256v1) — minimal, portable, and widely supported.
- LibreSSL-based keygens (macOS) default to explicit parameters — verbose, less compatible.
While the formats are functionally equivalent, they're not always compatible.
Checking Your Key
If you've created a key and added it to a stack or image source and are getting an x509
error, use the following pattern to check your key.
openssl ec -in YOURKEYFILENAME -text -noout
And check to see if there is a line: ASN1 OID: prime256v1
If you do, the key should work, if its not ping us on Slack or leave a comment here. Its likely something else.
If you do not see that line and want to convert the private key to named curve from explicit parameters use the following pattern:
openssl ec -in YOURKEYFILENAME -out NEWFILENAME -param_enc named_curve
The other option is to use OpenSSL directly on Mac or generate the keys from within a container.