.Ssh

Understanding SSH id_ed25519 Keys

Learn what ~/.ssh/id_ed25519 is, how Ed25519 SSH keys work, how to create and use them, and how to protect, inspect, rotate, and troubleshoot them.

What Is ~/.ssh/id_ed25519?

SSH, or Secure Shell, is a protocol and toolset for secure remote access and related operations. OpenSSH is a widely used implementation that provides commands such as ssh, ssh-keygen, ssh-agent, and ssh-add.

id_ed25519 is the conventional filename for an Ed25519 SSH private key. Its usual location is:

~/.ssh/id_ed25519

The matching public key normally has this filename:

~/.ssh/id_ed25519.pub

The private key proves that you control an identity. It must remain secret. The public key is designed to be copied to servers and services that should trust the corresponding private key.

How Ed25519 Public-Key Authentication Works

Ed25519 is a modern elliptic-curve public-key signature algorithm commonly supported by current OpenSSH versions. An Ed25519 key pair contains related but different key materials:

  • The private key stays on the client device and creates authentication signatures.
  • The public key is installed on the remote system or registered with a service.
  • During login, the client proves that it can use the private key without sending the private key to the server.
  • The server accepts the login when the signature verifies against an authorized public key.

This is called public-key authentication: a client proves it controls a private key corresponding to a public key that the destination trusts.

Ed25519 and RSA are different key algorithms. Their private key files are not interchangeable, even though both can be used for SSH authentication. RSA remains useful where older compatibility requirements exist, while Ed25519 is a common modern choice. See RSA SSH keys for comparison with RSA-specific files.

SSH Key Files and Their Roles

File or location — Typical contents — Secret or shareable — Purpose

~/.ssh/id_ed25519 — Ed25519 private key — Secret — Client identity used to create signatures.

~/.ssh/id_ed25519.pub — Matching public key — Shareable with intended destinations — Installed to authorize the private key.

~/.ssh/authorized_keys — One or more authorized public-key entries — Server-side configuration, not generally secret — Controls which keys may authenticate as one server account.

~/.ssh/config — SSH client host rules — Usually not secret, but protect it from unwanted modification — Selects users, hosts, keys, and connection options.

ssh-agent memory — Decrypted private keys held by a running agent — Sensitive — Avoids repeatedly entering passphrases during an active session.

SSH clients may automatically try conventional identity filenames such as id_ed25519, id_rsa, and other supported defaults. The exact behavior depends on the OpenSSH version and configuration. Multiple identities can exist in ~/.ssh, so explicit key selection is often useful.

Related conventional files include SSH client configuration, known hosts, and other algorithm-specific identities such as ECDSA keys.

Generating an Ed25519 Key Pair

Use ssh-keygen to create a private/public key pair. This command uses the default Ed25519 type and normally proposes ~/.ssh/id_ed25519 as the output path:

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

The identifying comment does not authenticate you. It helps you recognize the key later, especially when several keys are registered with different services.

When prompted, choose a strong passphrase. A passphrase is a secret that encrypts and protects the private key file at rest. It reduces the damage caused if somebody obtains a copy of the file. You will usually enter it when the key is first used, or load the key into an agent to avoid repeated prompts.

When ssh-keygen asks for a filename, do not blindly accept the default. Overwriting an existing private key can remove your ability to authenticate to every destination that trusts the old public key.

To create a separate key for a work account or particular service, choose a unique filename:

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

This creates:

~/.ssh/id_ed25519_work
~/.ssh/id_ed25519_work.pub

Installing the Public Key

Only the public key, or the text from the .pub file, should be installed on a destination.

Unix Server Accounts

A server account commonly authorizes SSH keys in:

~/.ssh/authorized_keys

The entry must belong to the target account. For example, a key placed in the administrator's authorized_keys does not authorize login as an unrelated user.

If an existing login method is available, such as a password, OpenSSH commonly provides ssh-copy-id:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server.example

This appends the public key to the remote account's authorization file. The initial login method must already be permitted.

You can also append the complete single-line public-key text manually to the target account's authorized_keys. Do not introduce line breaks inside the key entry.

Source-Control Hosting

For a Git hosting service, open the account's SSH key settings and paste the contents of the public file:

cat ~/.ssh/id_ed25519.pub

Register the key with the correct account. Git access then uses the service's SSH account, often named git, while the registered public key identifies your hosting account.

Using an Ed25519 Key with SSH

Default Identity

If the key is at the conventional path and the client discovers it automatically, connect normally:

ssh user@server.example

Explicit Identity Selection

Use -i to select a particular private key for one connection:

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

The argument to -i is the private key path, not the .pub path.

Host Configuration

For repeated connections, put a host entry in ~/.ssh/config:

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

Then connect with the alias:

ssh work-server

IdentityFile specifies the private key. IdentitiesOnly yes tells the client to use configured identities rather than offering every key available through an agent. This is useful when an agent has many keys loaded or when a server limits the number of failed authentication attempts.

Using a Separate Identity for Git

An SSH host alias can select a distinct key for Git:

Host git-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_work
  IdentitiesOnly yes

A repository remote can use the alias:

git@git-work:organization/repository.git

The alias causes SSH to apply the matching Host configuration while the actual network host remains the value of HostName.

Using ssh-agent

ssh-agent is a background process that can retain decrypted private keys for an active user session. After loading a passphrase-protected key, SSH can use it without asking for the passphrase on every connection.

Load the default key with:

ssh-add ~/.ssh/id_ed25519

List fingerprints of keys currently loaded in the agent:

ssh-add -l

Agent behavior differs by operating system and desktop environment. Some systems integrate an agent with a keychain or credential manager; others provide only a session-specific agent. A key loaded in one terminal session may not be available after a restart. Reload it when necessary and use platform-appropriate secure credential integration where available.

Permissions and Secure Storage

OpenSSH checks ownership and permissions to reduce the chance that another local user can read or modify key material. Typical Unix permissions are:

Path — Typical mode — Reason

~/.ssh — 700 — Only the owner can access the directory.

Private key — 600 — Only the owner can read and write the key.

Public key — 644 — The key is shareable, while only the owner modifies the file.

authorized_keys — 600 — Restricts modification of the server's authorized-key list.

Set common local permissions with:

chmod 700 ~/.ssh && chmod 600 ~/.ssh/id_ed25519 && chmod 644 ~/.ssh/id_ed25519.pub

Use the actual filenames when working with separately named keys. Also verify that the files and directories are owned by the intended user. Overly permissive permissions can cause OpenSSH to reject a private key or ignore a server-side authorization file.

  • Never commit a private key to a repository.
  • Never paste a private key into a ticket, public service, chat, or email.
  • Do not upload a private key to a web form for troubleshooting.
  • Back up private keys only in encrypted, access-controlled storage.
  • Store the passphrase separately from the backup when practical.
  • Plan recovery before losing the only copy of a key. A backup is useful only if it can be restored securely.

Inspecting and Validating Keys

Display the Public Key

Display the public key when copying it to an intended service:

cat ~/.ssh/id_ed25519.pub

A normal public-key line contains an algorithm name, encoded key data, and optionally a comment. The private key should not be displayed for this purpose.

Derive a Public Key from a Private Key

If the private key remains available but the .pub file is missing, derive the public-key text:

ssh-keygen -y -f ~/.ssh/id_ed25519

Compare the result with the public key registered on the destination. Protect the terminal output according to your local security practices, even though the derived material is public.

Compare Fingerprints

A fingerprint is a short identifier derived from a public key. It is convenient for comparing a local key with an installed or registered key:

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

Matching fingerprints indicate that the compared public keys are the same. A mismatch means the keys differ; check for the wrong file, wrong account, truncation, or an old registration.

Trace Authentication Attempts

Use verbose mode to observe identity selection and server responses:

ssh -vvv user@server.example

Look for which identity files are discovered, which agent keys are offered, and whether the server accepts or rejects each attempt. Avoid sharing verbose logs without reviewing them for usernames, hostnames, paths, and other sensitive information.

Key Rotation, Loss, and Compromise

Planned Rotation

Create a replacement with a new filename so the old key remains available during the transition:

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_2026 -C "user-2026"
  1. Generate the replacement key without overwriting the old private key.
  2. Install the new public key on every required server and service.
  3. Test access using ssh -i or a temporary host configuration.
  4. Remove the old public key from each destination only after the new key works.
  5. Retire or securely delete the old private key according to your recovery policy.

Adding the new key before removing the old one prevents accidental lockout.

Suspected Exposure

If a private key may have been exposed, treat it as compromised. Immediately remove its public-key authorization from every server, hosting account, and other destination that trusts it. Then create and deploy a replacement key. Changing a comment or renaming the file does not make an exposed private key safe.

Forgotten Passphrase

A forgotten passphrase generally cannot be recovered from the encrypted private key. Do not try to bypass it. Generate a new pair, install the new public key, verify access, and revoke the old public-key authorization. If an agent still has the unlocked key loaded, use it only to complete the controlled replacement process.

Common SSH Problems

Permission denied (publickey)

  • The matching public key may not be installed for the target user or service account.
  • SSH may have selected the wrong private key.
  • The intended key may not be loaded in the agent and may not have been discovered as a file identity.
  • The username, hostname, or Git remote may be incorrect.

Run ssh -vvv, test with ssh -i, and compare the local public-key fingerprint with the destination's installed or registered key.

WARNING: UNPROTECTED PRIVATE KEY FILE

The private key is probably readable by another local user. Set it to owner-read/write only:

chmod 600 ~/.ssh/id_ed25519

Also verify ownership and the permissions of ~/.ssh.

The Wrong Key or Account Is Selected

Many loaded agent keys can cause the client to offer an unintended identity, or the server may stop trying after too many attempts. Inspect the agent with:

ssh-add -l

Use ssh -i for a one-time test, then configure IdentityFile and IdentitiesOnly yes for repeatable host-specific selection.

The Key Stops Working After Restart

The key may have been loaded only into a session-specific agent. Confirm that an agent is available and reload the key with:

ssh-add ~/.ssh/id_ed25519

Operating-system keychain integration may provide more persistent, protected agent behavior.

A Manually Installed Key Is Rejected

  • Confirm that the entry is complete and remains on one line.
  • Confirm it is in the correct user's ~/.ssh/authorized_keys.
  • Check remote ownership and restrictive permissions for ~/.ssh and authorized_keys.
  • Review server-side SSH authentication logs when administrative access is available.

Common SSH Key Operations

Goal — Command or configuration — Notes

Generate key — ssh-keygen -t ed25519 -C "user@example.com" — Choose a passphrase and avoid overwriting an active identity.

View public key — cat ~/.ssh/id_ed25519.pub — Share only with intended destinations.

Load agent — ssh-add ~/.ssh/id_ed25519 — Requires an active agent.

List agent keys — ssh-add -l — Shows loaded key fingerprints.

Inspect fingerprint — ssh-keygen -lf ~/.ssh/id_ed25519.pub — Compare with the expected registration.

Verbose connection test — ssh -vvv user@server.example — Shows identity discovery and authentication attempts.

Use a host-specific identity — IdentityFile ~/.ssh/id_ed25519_work with IdentitiesOnly yes — Place in ~/.ssh/config.

Exam-Relevant Notes

  • id_ed25519 is conventionally the private key; id_ed25519.pub is the matching public key.
  • The private key stays with the user; the public key is installed on the destination.
  • authorized_keys belongs to the account whose SSH access it controls.
  • ssh-keygen creates keys, ssh-add loads keys into an agent, and ssh-add -l lists loaded identities.
  • IdentityFile selects a private key in SSH configuration.
  • IdentitiesOnly yes limits authentication to configured identities.
  • A passphrase protects a private key at rest but does not replace server-side key revocation.
  • After compromise, remove the old public key everywhere it is authorized and deploy a replacement.