Competitor MappingReference node
Profile SSH keys
Competitor mapping for Linode (Akamai).
This page is a structured knowledge reference. For step-by-step migration guidance, see the migration guide.
Details
- Provider
- Linode (Akamai)
- Service term
- Profile SSH keys
- Provider documentation
- External reference
Behavioral divergences
Profile SSH keys
Quake AI concept: Key Pairs
- Linode manages SSH keys under the Profile resource, with `GET /v4/profile/sshkeys`, `POST /v4/profile/sshkeys`, `GET /v4/profile/sshkeys/{sshKeyId}`, `PUT /v4/profile/sshkeys/{sshKeyId}`, and `DELETE /v4/profile/sshkeys/{sshKeyId}`. That is account/profile-level key management rather than Nova-style key pairs managed as a compute resource.
- When creating a Linode, SSH access is supplied through request fields named `authorized_keys` and `authorized_users`, not by attaching a Nova key pair object to a server. The create instance page says `authorized_keys` is an array of strings and `authorized_users` is an array of usernames whose SSH public keys are added when creating the Linode.
- The Linode create-instance documentation describes SSH keys as part of initial provisioning, with no post-create SSH key attachment or modification behavior documented on that page. In OpenStack, key pairs are typically selected for a server at boot and are not a separate account-profile key store.
- The Linode API summary does not present SSH keys as an instance-local resource; it groups them under Profile. That implies a user-centric key store shared across Linode creation flows rather than a per-project or per-instance Nova `key_pairs` collection.
Related
Diverges from (incoming)
Citations
- Linode (Akamai)
- Linode (Akamai)
These citations record configured source URLs in the knowledge graph. They are not a live platform walk verification date.