How to Back Up Your SSH Keys on Windows Securely

/ Backup, Software / By / / security, software, ssh, ssh keys

How to Back Up Your SSH Keys on Windows

If you use SSH keys to connect securely to Linux servers, VPSs, hosting accounts or other remote systems, backing up your keys is important.Losing an SSH private key can mean losing access to servers or having to generate a replacement key and install it on every server you manage.

This guide explains which SSH key files you need to back up on Windows and how to store them securely.

Where Are SSH Keys Stored on Windows?

If you created your SSH keys using the standard Windows OpenSSH tools, they will normally be stored in:

C:\Users\YourUsername\.ssh\

For an Ed25519 SSH key, the two main files are usually:

id_ed25519
id_ed25519.pub

Although these files have similar names, they have very different purposes.

What Is id_ed25519?

The file:

id_ed25519

is your private SSH key.

This is the most important file to back up.

The private key proves your identity when you connect to a server. Anyone who obtains a usable copy of your private key could potentially authenticate as you on servers where the corresponding public key has been authorised.

For this reason, your private key should never be emailed, uploaded to an insecure location, placed in a public repository or shared with another person.

Ideally, your private key should also be protected with a strong passphrase.

What Is id_ed25519.pub?

The file:

id_ed25519.pub

is your public SSH key.

This is the key that can safely be copied to remote servers, normally by adding it to an account’s:

~/.ssh/authorized_keys

file.

Unlike the private key, the public key does not need to be kept secret.

It is still sensible to include the .pub file in your backup so that you have a complete copy of the original key pair.

Which Files Should You Back Up?

For a straightforward SSH key backup, save both:

id_ed25519
id_ed25519.pub

The private key is the critical file.

If you lose the public key but still have the private key, you can recreate the public key.

If you lose the private key, however, it cannot be recreated from the public key; you would need to generate a new SSH key pair and install the new public key on every server that previously trusted the old key.

Can You Recreate the Public Key?

Yes.

If you have your id_ed25519 private key but have lost the corresponding .pub file, you can generate the public key again.

Open PowerShell in the directory containing the private key and run:

ssh-keygen -y -f id_ed25519 > id_ed25519.pub

If the private key is protected with a passphrase, you will be prompted to enter it.

The resulting id_ed25519.pub file can then be installed on servers in the normal way.

Where Should You Store Your SSH Key Backup?

Because the private key is sensitive, don’t simply copy it to an unencrypted USB drive, cloud folder or network share.

A password manager that supports secure file attachments can be a convenient option.

For example, you could create a password-manager entry for the SSH key and securely store:

  • The id_ed25519 private key as an attachment
  • The id_ed25519.pub public key as an attachment
  • The private key’s passphrase in the password field
  • A description explaining what systems the key is used for

The password-manager database itself should, of course, be protected with a strong master password and backed up appropriately.

What About known_hosts?

You may also find a file called:

known_hosts

inside your .ssh directory.

This contains information about SSH servers you have previously connected to, including their host keys.

It isn’t required to restore your SSH identity, so losing it won’t prevent you from using your private key.

However, backing it up can be useful because it preserves the server identities that your computer has previously trusted.

Be cautious when restoring an old known_hosts file, though. Server host keys can legitimately change after a server is rebuilt or reconfigured, so unexpected host-key warnings should always be investigated rather than bypassed.

Test Your Backup

A backup is only useful if you can restore it.

After creating your backup, make sure that:

  1. The private key is actually present in the backup.
  2. You know the passphrase required to unlock it.
  3. The backup itself is encrypted and protected.
  4. You have another backup of the password-manager database or encrypted storage containing it.

You don’t necessarily need to test the key against a production server. The important thing is to make sure that the private key can be recovered and read by OpenSSH.

For example, after restoring the private key to a secure test location, you can verify that OpenSSH can read it with:

ssh-keygen -y -f id_ed25519

If successful, this will output the corresponding public key without modifying the private key.

Restoring an SSH Private Key on Windows

If you need to restore the key to another Windows computer, place the private key back into the user’s .ssh directory, for example:

C:\Users\YourUsername\.ssh\id_ed25519

You can then connect to a server using:

ssh username@example.com

Or, when using a non-standard SSH port:

ssh -p 2222 username@example.com

If the key is protected with a passphrase, OpenSSH will ask for it when required.

Depending on how the file was restored, you may also need to check its Windows file permissions so that the private key isn’t accessible to other users.

Should You Use the Same SSH Key Everywhere?

Using one SSH key for several servers is convenient, but it also increases the impact if that private key is ever compromised.

For environments containing multiple important servers, consider using separate keys for different purposes, customers, environments or administrative roles.

Whichever approach you choose, keep an inventory of your keys so you know which servers need updating if a key ever has to be revoked.

Summary

For a typical Windows OpenSSH installation using Ed25519 keys, the most important files are:

id_ed25519      Private key — secret and essential
id_ed25519.pub  Public key — safe to distribute
known_hosts     Previously trusted server host keys — optional backup

The key point is simple: protect and back up your private key.

If you still have id_ed25519, you can regenerate its public key. If you lose the private key, it cannot be recovered from id_ed25519.pub.

Store private keys only in encrypted, access-controlled backups, protect them with strong passphrases, and make sure your backup strategy itself has redundancy.

A few minutes spent securely backing up your SSH keys can save a considerable amount of work if a computer fails or needs to be replaced.