How to Set Up SSH Keys

Use Ed25519. If you are setting up an SSH key today, generate an Ed25519 key with ssh-keygen -t ed25519, because it is fast, secure, and now supported almost everywhere, and it is the right default over older RSA keys. Secure Shell (SSH) keys let you log in to a server or a service such as GitHub without typing a password, using a matched pair of a private key you keep and a public key you share.

The guide walks through generating a key pair, adding the public key to a server or to GitHub, and keeping keys healthy, then explains when long-lived keys become a liability and short-lived SSH certificates are the better answer. The commands work on macOS, Linux, and Windows, and the steps are kept clean so you can copy them straight into a terminal.

What you need before you start

You need a terminal and a working OpenSSH client, which ships by default on macOS, on modern Windows, and on every mainstream Linux distribution. Check that it is present by asking for the version, and any recent release is fine for what follows.

ssh -V
# example output: OpenSSH_9.6p1, LibreSSL 3.3.6

You also need to know where SSH keys live, which is the .ssh directory inside your home folder. Commands in this guide write keys there by default, and you rarely need to change that location unless you keep separate keys for separate accounts.

How to generate an SSH key pair

Generating a key pair takes one command and a couple of prompts. The steps that follow produce an Ed25519 key, which is the recommended algorithm in 2026.

1. Run the key generator with the Ed25519 algorithm and a label so you can recognize the key later.

   ssh-keygen -t ed25519 -C "[email protected]"
   

2. Accept the default file location when prompted, which creates the private key at ~/.ssh/id_ed25519 and the public key at ~/.ssh/id_ed25519.pub. Press Enter to accept it.

3. Set a passphrase when asked. A passphrase encrypts the private key on disk, so a stolen key file is useless without it, and choosing a strong one is worth the small friction at login.

After the command finishes you have two files. The private key stays on your machine and is never shared, and the public key ending in .pub is the half you copy to servers and services. If you ever need to generate an RSA key for an old system that lacks Ed25519 support, use ssh-keygen -t rsa -b 4096, but prefer Ed25519 everywhere it works.

How to add your SSH key to a server or GitHub

To log in to a server with your key, the server needs your public key in its list of authorized keys. The ssh-copy-id command does this in one step by appending your public key to the ~/.ssh/authorized_keys file on the server.

ssh-copy-id user@your-server-host

If ssh-copy-id is not available, copy the key manually by printing your public key, pasting it into ~/.ssh/authorized_keys on the server, and making sure the file is readable only by its owner. After the key is in place, ssh user@your-server-host logs you in without a password.

Adding a key to GitHub follows a similar idea, except you paste the public key into the web interface rather than a file. Copy the public key to your clipboard, open GitHub, go to Settings, then SSH and GPG keys, choose New SSH key, and paste it in.

# macOS
pbcopy < ~/.ssh/id_ed25519.pub
# Linux (with xclip installed)
xclip -selection clipboard < ~/.ssh/id_ed25519.pub
# Windows (PowerShell)
Get-Content ~/.ssh/id_ed25519.pub | Set-Clipboard

Test the GitHub connection with ssh -T [email protected], which greets you by username when the key is recognized. For servers you reach often, an entry in your SSH config file saves typing, and our article on SSH configuration (ssh_config) covers host aliases and default users.

SSH key hygiene and the ssh-agent

A passphrase protects your private key, but typing it on every connection gets tiring, which is what the ssh-agent solves. The agent holds your decrypted key in memory for the session, so you enter the passphrase once and connect freely after that. Start the agent and add your key with two commands.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

The harder problem arrives at scale, when one key becomes many. Over time a team generates keys on laptops, servers, and CI systems, and those keys almost never expire and rarely get cleaned up, so an old key on a former employee’s machine can keep working long after it should. Because a public key sitting in an authorized_keys file grants access until someone removes it by hand, unmanaged keys become a standing liability, a problem our article How to Manage SSH Keys covers in depth. Good hygiene means using a passphrase on every key, keeping one key per person and machine rather than sharing, and removing keys the moment they are no longer needed. For a broader look at the algorithms behind these keys, our article Comparing SSH Keys: RSA, DSA, ECDSA, or EdDSA? explains why Ed25519 wins today.

When to use SSH certificates instead of keys

Manual key management stops scaling when you have more than a handful of servers and people. Every new host needs every authorized public key, every departure means hunting keys down across a fleet, and there is no expiry to fall back on, which is why large teams move from static keys to short-lived SSH certificates. A certificate is a public key that a trusted certificate authority (CA) has signed for a limited time, so instead of a server holding a long list of individual keys, it trusts the CA and accepts any certificate the CA issues, and the certificate stops working on its own when it expires.

Short-lived certificates are the alternative to piling up keys. Our article How to Configure SSH Certificate-Based Authentication walks through the OpenSSH setup, and our article Credentials vs Cryptographic Identity explains the reasoning behind the move from static keys to issued identity. Teleport issues these short-lived SSH certificates through Teleport Zero Trust Access, granting access after a user authenticates with the company identity provider and multi-factor authentication, so access follows verified identity and expires automatically rather than living forever in a file.

Conclusion

Setting up an SSH key comes down to generating an Ed25519 pair, protecting the private key with a passphrase, and adding the public key to the servers and services you use. The basic setup is enough for a single developer, but keys multiply and never expire, so as a team and a fleet grow, short-lived SSH certificates that tie access to a verified identity and expire on their own are the better answer.