PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchTo move a conventional file-based SSH identity, copy the private key and its matching .pub file from the old computer’s ~/.ssh directory to the same directory on the new computer, using an encrypted transfer method. On the new computer, restrict the private-key permissions, start ssh-agent if necessary, run ssh-add, and test the host you need to access. The file without .pub is the secret; the .pub file is safe to register with a service or server.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
You can use one key on multiple computers, but a separate ED25519 key per device limits the damage if one computer is lost or compromised. The right choice depends on whether continuity or device isolation matters more.
As an Amazon Associate I earn from qualifying purchases.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →Identify exactly what you are moving
SSH keys normally live in the user account’s ~/.ssh directory. A typical ED25519 pair is:
id_ed25519— the private key. Treat it like a password and never send it to another person, upload it to an account setting, or paste it into a ticket.id_ed25519.pub— the public key. This is the half you add to a Git hosting account or a server’sauthorized_keysfile.
The filename may be different if you created a key for a particular project or host, such as work_ed25519. Do not assume that id_ed25519 is the key in use. On the old computer, list the directory and note every candidate pair:
#1 Best Overall
- Certified to FIPS 197 - High-level information security standard approved by the U.S. Government
- Brute-Force Password Attack Protection - Data is automatically erased after 6 failed access attempts. The data and encryption key are securely destroyed and the crypto drive is reset
- Rugged Double-Layer Waterproof* Design - Protects the crypto drive against knocks, drops, break-in and submerging in water. The electronics are shielded by a hardended inner case. The rubberised silicone outer casing provides a final layer of protection
- Auto-lock - The crypto drive will automatically encrypt all data and lock when removed from a PC/Mac or when the screen saver or "computer lock" function is activated on the host PC/Mac
- Secure Entry - Data cannot be accessed without the correct high-strength alphanumeric 8-16 character password. A password hint option is available. The password hint cannot match the password
ls -la ~/.ssh
Look for a private file and a public file with the same base name. Configuration files can also determine which identity SSH chooses, so preserve ~/.ssh/config when you rely on host-specific settings, aliases, ports, or an explicit IdentityFile.
Choose between copying the old key and generating a new one
Both approaches are valid. A copied key preserves the identity already authorized on your hosts; a new key gives each computer an independent credential.
Recommended Free Tools
| Choice | Use it when | What you must do | Main trade-off |
|---|---|---|---|
| Copy the existing pair | You need uninterrupted access and can protect the transfer and the new computer. | Move the private and public files securely, load the private key into the new computer’s agent, and verify access. | A lost, stolen, or compromised new computer exposes the same credential used elsewhere. Replace it everywhere if compromise is suspected. |
| Generate a new ED25519 pair | You want per-device isolation, or you cannot transfer the old private key safely. | Create a new key, add its public text to every Git host or server, load the private key, and remove the old registration when appropriate. | Every account and server must be updated before the new computer has access. |
GitLab documents that the same SSH key can be used on multiple devices, while recommending a new key for each device to reduce the impact of loss. GitLab and GitHub documentation both identify ED25519 as the preferred ordinary key type and show generating one with ssh-keygen -t ed25519.
Prepare a secure transfer
Do not email the private key, paste it into chat, or put it in an unencrypted cloud-synchronization folder. GitLab specifically recommends a password manager or an encrypted USB drive for moving the private file. The transfer medium should be encrypted, access-controlled, and removed or locked after the copy.
What to copy for a conventional key
- The private file, for example
id_ed25519. - The matching public file, for example
id_ed25519.pub. ~/.ssh/config, if it contains anIdentityFile, host alias, non-default port, or other settings required by your workflow.
You do not need to copy unrelated known-host records to authenticate, although retaining known_hosts can preserve host fingerprints and avoid re-approving servers. Never copy a private key to a shared or publicly accessible location while preparing the transfer.
Rank #2
- Certified to FIPS 197 - High-level information security standard approved by the U.S. Government
- Brute-Force Password Attack Protection - Data is automatically erased after 6 failed access attempts. The data and encryption key are securely destroyed and the crypto drive is reset
- Auto-lock - The crypto drive will automatically encrypt all data and lock when removed from a PC/Mac or when the screen saver or "computer lock" function is activated on the host PC/Mac
- Secure Entry - Data cannot be accessed without the correct high-strength alphanumeric 8-16 character password. A password hint option is available. The password hint cannot match the password
- SuperSpeed USB 3.0 - Transfer all your confidential files and folders faster than ever before. Works on both PC & Mac
Copy with an encrypted USB drive
- Unlock or mount the encrypted drive on the old computer.
- Copy the private key, its matching
.pubfile, and any required SSH configuration onto the drive. - Eject the drive, connect it to the new computer, and copy the files into that computer’s SSH directory.
- Eject it again and remove the temporary copies from the drive according to the drive’s secure-delete or reformat procedure.
If you use a password manager instead, store the private-key text only in a protected, access-controlled record and delete the temporary export after importing it on the new computer.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsInstall the key on macOS or Linux
On Unix-like systems, the destination is the new computer’s home directory, not another user’s home and not the system-wide SSH directory.
- Create the directory if it does not exist:
mkdir -p ~/.ssh. - Copy the pair into it. For a key named
id_ed25519, the resulting paths should be~/.ssh/id_ed25519and~/.ssh/id_ed25519.pub. - Restrict the private file so only your account can read it:
chmod 600 ~/.ssh/id_ed25519. - If you copied a custom filename, apply the same permission to that file, for example
chmod 600 ~/.ssh/work_ed25519. - Start an agent in the current shell:
eval "$(ssh-agent -s)". - Load the key:
ssh-add ~/.ssh/id_ed25519. Substitute the actual path when the filename is different.
If the key is passphrase-protected, ssh-add prompts for that passphrase. The passphrase unlocks the local private key; it is not uploaded to a Git service or remote server.
Preserve host-specific selection
When several keys are present, add an entry to ~/.ssh/config so the intended identity is selected for the intended host:
Host git-work
HostName gitlab.com
User git
IdentityFile ~/.ssh/work_ed25519Use the alias in your Git remote or SSH command only if it matches your configuration. Otherwise, load the chosen file explicitly with ssh-add /path/to/private-key and connect to the normal hostname.
Rank #3
- Certified to FIPS 197 - U.S. Government Approved High Level Information Security Standard.
- Protection against brute force password attacks - Data is automatically erased after 6 unsuccessful access attempts. The data of the USB flash drive type c encryption with dual connectors is destroyed and the cryptographic drive is reset.
- Durable dual-layer waterproof design* — Protects the crypto reader from bumps, drops, run-in and immersion in water. The electronics are protected by a hardened internal case. Rubberized silicone outer case provides a final layer of protection.
- Auto-Lock —The cryptographic key automatically encrypts all data and locks when removed from a PC/Mac or when screen protection or "computer lock" is enabled.
- Secure Entry —Data on these flash drives cannot be accessed without the correct alphanumeric password of 8 to 16 characters. A password indication option is available for this flash drive. The hint cannot match the password.
Install the key on Windows
Windows commonly has more than one SSH environment. Git for Windows (Git Bash), Windows OpenSSH, and WSL can have different home directories and different agents. Copy and load the key in the environment that actually runs your Git or SSH command.
Git for Windows or Windows OpenSSH
- Open a non-elevated PowerShell or Git Bash terminal as the account that will use SSH.
- Place the files in that account’s SSH directory, normally
C:Usersyour-name.sshfor Windows OpenSSH or the corresponding home directory shown byecho $HOMEin Git Bash. - Start the Windows
ssh-agentservice according to your Windows installation’s service controls. Do not run the everyday Git commands as an administrator merely to work around an incorrect home directory. - Add the key with
ssh-add ~/.ssh/id_ed25519in the same environment that will run Git. - Confirm that the agent lists it with
ssh-add -l.
GitHub’s Windows instructions likewise start the ssh-agent service and add the key from a non-elevated terminal. If Git Bash and PowerShell show different ~/.ssh locations, that is expected: use one location consistently or copy the key deliberately into the environment you selected.
WSL
WSL has its own Linux home directory. A key copied to C:Usersyour-name.ssh is not automatically the same key as one in WSL’s ~/.ssh. If Git runs inside WSL, copy the files into the WSL user’s ~/.ssh, set the private file to mode 600, start the WSL agent, and run ssh-add there. If Git runs in Windows, load the Windows copy instead.
Register a newly generated key
A copied key already has its public half registered wherever the old key was authorized. A newly generated key does not. On the new computer:
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Generate an ED25519 pair, for example
ssh-keygen -t ed25519. Choose a clear filename when prompted if you keep multiple identities. - Load the private file into the agent with
ssh-add /path/to/private-key. - Display the complete public-key line, for example
cat ~/.ssh/id_ed25519.pubon macOS/Linux or the equivalent command in your Windows shell. - Copy the entire line, including the key type and comment, into each Git account or server that should accept the new computer.
- Keep the private file local. The account service needs only the public-key text.
- After confirming the replacement works, remove the old public-key registration from services or servers when you no longer need it.
Never paste the file without .pub into GitHub, GitLab, a server’s key field, or any support form. If a private key was exposed, assume it is compromised: revoke the corresponding public key everywhere and create a replacement.
Rank #4
- FIPS 197 with XTS-AES 256-bit Encryption: Provides business-grade security with hardware-based encryption to protect your sensitive data
- Brute Force and BadUSB Attack Protection: Safeguards against unauthorized access attempts and malicious USB attacks with digitally-signed firmware
- Multi-Password Option with Complex/Passphrase modes: Offers flexible password configuration options to meet various security requirements and user preferences
- New Passphrase Mode: Enhanced security feature allowing users to create longer, more memorable password phrases for easier access without compromising protection
- Dual Read-Only (Write-Protect) Settings: Enables write protection functionality to prevent accidental data modification or deletion when needed
Verify the transfer before relying on it
Test the exact service or server that matters to you, rather than only checking that a file exists.
- List keys currently loaded in the agent:
ssh-add -l. The transferred key should appear. - Test the relevant Git host, such as
ssh -T [email protected]orssh -T [email protected], and follow that service’s current verification response. - For a private server, connect with the same hostname, port, and username used by your application.
- If you use a custom host alias, test the alias from
~/.ssh/config, not only the underlying hostname.
A successful test confirms that the new computer can offer a loaded private key whose matching public key is registered at the destination. It does not mean every other host has been updated.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Troubleshoot “permission denied” and repeated key prompts
The agent does not contain the key
Run ssh-add -l. If the list is empty or the expected fingerprint is absent, start the agent in the current shell and add the actual path again:
Free tools Windows power users keep installed
One-click scans. No signup required.
eval "$(ssh-agent -s)"ssh-add ~/.ssh/id_ed25519
On Windows, make sure you started the agent used by the same Git, PowerShell, Git Bash, or WSL environment that runs the connection.
SSH is reading a different home directory
Compare the location shown by your shell’s home-directory variable with the directory where you copied the key. Git for Windows and WSL can point to different homes. A key in one environment does not automatically appear in the other.
Best Value
- FIPS 140-3 Level 3 (Pending) Certified Military-Grade Security
- OS/Device Independent
- XTS-AES Hardware Encryption
- Enforced Alphanumeric PIN
- Multi-PIN (Admin and User) Option
The private-key permissions are too broad
On macOS/Linux, apply chmod 600 ~/.ssh/id_ed25519 to the actual private file. SSH may refuse to use a key that other accounts can read. Check ownership and the path if the command still fails.
The public key is not registered or does not match
Compare the public-key line registered at the service with the .pub file that belongs to the private key you loaded. For a server, verify that the complete line is in the intended account’s authorized_keys. Copying files does not add a new key to an account automatically.
The wrong identity is selected
Multiple keys can cause SSH to offer an unintended one. Load only the needed key for a quick test, use an explicit IdentityFile in ~/.ssh/config, or add the intended path with ssh-add /path/to/private-key. Confirm that the hostname in the configuration matches the hostname in your command.
The old computer was lost after the copy
If the old machine, a backup, or the new machine may have exposed the private key, remove that key’s public registration from every Git service and server, generate a replacement ED25519 key, and register the replacement. A copied key remains valid on the old registrations until you revoke it.
FIDO2 and security-key-backed identities are different
Keys created with FIDO2-backed types such as ed25519-sk or ecdsa-sk are tied to a hardware authenticator. They are not ordinary private-key files that can be copied to a USB drive or another computer. Leave the credential on the authenticator, reconnect that authenticator to the new computer, and use the resident-key import or load process documented for your OpenSSH version, such as ssh-add -K or ssh-keygen -K where supported.
GitLab states that OpenSSH 8.2 or later is required for the cited ed25519-sk and ecdsa-sk key types. If the new computer has an older OpenSSH release, update the client or use the compatibility procedure for that authenticator rather than attempting to extract a private key.
Quick Recap
After the move: reduce future risk
- Keep the private key protected by a strong passphrase and restrictive file permissions.
- Prefer a separate ED25519 key per computer when you can manage the additional registrations.
- Maintain a list of services and servers where each public key is authorized, so a lost device can be revoked quickly.
- Keep encrypted backups only when you understand who can unlock them; an unencrypted backup is another copy of the credential.
- Remove temporary transfer files from the old computer, USB drive, password-manager export, and downloads folder.
- Never upload a private key to account settings. Public-key registration is the only step that belongs on a Git hosting service or server.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
