VMware ESXi and vSphere Cluster Management

Understanding the id_ed25519 SSH Key

Learn what id_ed25519 is, how Ed25519 SSH authentication works, how to create and use keys, and how to manage them securely.

id_ed25519 is the conventional filename for an Ed25519 SSH private key. SSH, or Secure Shell, is a protocol and toolset for secure remote access and related operations. This guide explains how the key pair works, how to create and install it, and how to protect and replace it.

SSH keys are normally stored in the hidden ~/.ssh directory inside your home directory. The filename is only a convention: you can choose a different name when generating a key.

What id_ed25519 means

An Ed25519 SSH key pair contains two related files:

• ~/.ssh/id_ed25519 is the private key. It is secret and must remain under your control.
• ~/.ssh/id_ed25519.pub is the matching public key. It is intended to be copied to systems and services that need to recognize you.

Ed25519 is a public-key signature algorithm commonly supported by modern OpenSSH versions. The name id_ed25519 is not a requirement imposed by the algorithm. For example, a work key could be named id_ed25519_work, producing a public key named id_ed25519_work.pub.

How Ed25519 public-key authentication works

Public-key authentication uses a private key held by the client and a corresponding public key recognized by the server. It avoids sending the private key to the server.

1. The server account stores your public key, commonly in its authorized_keys file.
2. When you connect, the SSH client identifies a candidate public key.
3. The server checks whether that public key is authorized for the requested account.
4. The server sends data that the client must authenticate.
5. The client uses the private key to create a digital signature. The private key itself is not transmitted.
6. The server verifies the signature with the stored public key. A valid signature demonstrates possession of the matching private key.

A private key is not a password, and an Ed25519 key is not a server host key. A user key authenticates a client to a server; a host key helps a client identify the server.

Create an Ed25519 key pair

ssh-keygen is the OpenSSH command-line utility for creating and inspecting keys. To create a conventionally named key pair, run:

ssh-keygen -t ed25519 -C "user@example.com"

The command normally proposes a path such as /home/username/.ssh/id_ed25519 on Linux or /Users/username/.ssh/id_ed25519 on macOS. Accept that path when this should be your default key. The command creates the private key and appends .pub for the public key.

When prompted, enter a nonempty passphrase. A passphrase is a secret that protects the private key when it is stored on disk. If someone copies an encrypted private key file, the passphrase makes immediate use more difficult. An SSH agent can remember an unlocked key so you do not have to enter the passphrase for every connection.

The comment helps people identify a key; it is not a secret and does not authenticate you. You can use a descriptive comment and a separate filename for another identity:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_work -C "work-device"

This creates ~/.ssh/id_ed25519_work and ~/.ssh/id_ed25519_work.pub. Use separate keys for different devices, users, organizations, or purposes when that separation makes access control and revocation clearer.

Install and use the public key

Only the public-key content should be copied to a remote service. Display it with:

cat ~/.ssh/id_ed25519.pub

Copy the complete single line into the appropriate location:

• For a remote Linux account, add it as a line in that account's ~/.ssh/authorized_keys file.
• For a source-control host, add it through the account's SSH-key settings.
• For another SSH-enabled service, use that service's mechanism for registering public keys.

Keep id_ed25519 on the client. Never upload it, commit it to a repository, paste it into an issue, or place it in a configuration repository.

When the default filename is used, SSH commonly finds it automatically:

ssh user@example.example

For a nondefault name or location, select the private key explicitly:

ssh -i ~/.ssh/id_ed25519_work user@example.example

The -i option selects the private key. The server still needs the matching .pub key in the target account or service.

Use ssh-agent and control key selection

ssh-agent is a process that holds unlocked private keys for SSH clients. Add a key with ssh-add:

ssh-add ~/.ssh/id_ed25519

The agent may request the key's passphrase. To list identities currently loaded in the agent, run:

ssh-add -l

SSH can consider keys from explicit options, client configuration, default key files, and the agent. If too many keys are offered, a server may reject the connection before SSH reaches the intended key. A host-specific configuration makes selection predictable:

Host work-server
  HostName ssh.example.com
  User deploy
  IdentityFile ~/.ssh/id_ed25519_work
  IdentitiesOnly yes

Place this in ~/.ssh/config. Now connect using the alias:

ssh work-server

IdentityFile names the intended private key. IdentitiesOnly yes tells the client to limit authentication to configured identities rather than trying many agent keys.

Secure storage and file permissions

The private key should be readable only by its owning user. Common Unix permissions are:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519

Exact ownership and permission requirements vary by operating system and SSH server policy. Check that the files are owned by the expected account and that no other local user can read the private key. Server-side SSH directories and authorized_keys may also be rejected when they are writable by inappropriate users.

Backups require care. Encrypt backup media or storage, restrict access, and keep enough recovery copies to avoid losing access if a device fails. A backup of an encrypted private key is useful only if its passphrase is also available through a secure recovery process. If the private key is permanently lost, it generally cannot be reconstructed from the public key; create a new pair and deploy the new public key instead.

Key fingerprints

A fingerprint is a short digest of a public key. It provides a convenient way to identify a key without comparing the entire key line.

ssh-keygen -lf ~/.ssh/id_ed25519.pub

Compare the displayed fingerprint with a trusted record or with the fingerprint of the public key installed on a server. Fingerprints are especially useful when auditing accounts, confirming which device owns a key, or checking that a replacement key was deployed.

Key lifecycle management

Keys are credentials and need ongoing management:

• Use separate keys for distinct devices, users, or purposes where appropriate.
• Label keys with useful comments such as a device, owner, purpose, or creation period. Do not put secrets in comments.
• Audit authorized_keys and service dashboards periodically. Remove keys that are obsolete or no longer attributable to a user or device.
• Rotate keys by generating a new pair, installing the new public key, testing access, and removing the old public key.
• If a private key may have been exposed, treat it as compromised. Generate and deploy a replacement immediately, then remove the former public key from every authorized location.

Ed25519 compatibility and alternatives

Ed25519 is generally a preferred SSH key type in modern OpenSSH environments because it is designed for public-key signatures and is broadly supported. Older servers, embedded systems, or organizational policies may require RSA instead. Select the type that both the client and server support and that your security policy permits; RSA is a compatibility alternative, not an identical choice for every environment.

Troubleshooting id_ed25519 connections

Permission denied (publickey)

• Confirm that the matching public key is in the target account's authorized_keys.
• Check the username, hostname, and private key path.
• Verify that the server and account permit public-key authentication.
• Check server-side ownership and permissions for the SSH directory and authorized_keys.
• Use ssh -v or ssh -vvv and confirm that the expected key is offered.
• Compare the public-key fingerprint on the client with the installed key.

ssh -vvv -i ~/.ssh/id_ed25519_work user@example.example

Private-key permissions are too open

This usually means another local user can read the private key, or the key has unsuitable ownership. Restrict the SSH directory and private key, then verify ownership:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_work

The correct key is not selected automatically

A nonstandard filename, several agent identities, or missing host configuration can cause this problem. Test with ssh -i, inspect loaded identities with ssh-add -l, and define IdentityFile plus IdentitiesOnly yes for the host.

Too many authentication failures

The agent may offer multiple keys before the intended key, while the server limits failed attempts. Remove unneeded identities from the agent or use a host entry with an explicit IdentityFile and IdentitiesOnly yes.

An older server rejects Ed25519

The server's SSH implementation or policy may lack Ed25519 support. Confirm its capabilities and organizational requirements. If necessary, create and use an approved compatible key type, such as RSA, rather than weakening the server's policy without authorization.

Practical checklist

1. Generate an Ed25519 pair with ssh-keygen.
2. Protect the private key with a strong, nonempty passphrase.
3. Share only the .pub file's content.
4. Install the public key in the intended account or service.
5. Use ssh-agent or host-specific SSH config when convenient.
6. Restrict file permissions and encrypt backups.
7. Record fingerprints and useful comments for auditing.
8. Rotate or revoke keys when devices, users, or credentials change.

For related material, see this SSH key reference.