# What is an SSH key?

> An SSH key is a public and private key pair used to sign in to servers and Git hosts without a password. How authorized_keys works and why keys outlive people.

URL: https://crunu.com/learn/ssh-key
Language: en
Updated: 2026-10-30

An SSH key is a pair of keys, a private key that stays with the user and a public key that is copied to servers and services, which lets the user prove their identity to an SSH server or a Git host by signing a challenge instead of sending a password.

## How it works

You generate the pair with `ssh-keygen`, keep the private key in `~/.ssh/`, ideally protected by a passphrase, and give the public key to anything you want to reach. On a server, accepted public keys live in a file, by default `~/.ssh/authorized_keys`, where "each line of the file contains one key" ([sshd manual](https://man.openbsd.org/sshd.8)). A Git host stores your public key in your account settings.

```text
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...EXAMPLE jonas@laptop
```

When you connect, the server checks that your signature matches a public key it holds. The private key never leaves your machine. Modern keys are usually [Ed25519](https://crunu.com/learn/ed25519).

`authorized_keys` lines can carry restrictions that are easy to forget: `from="pattern-list"` limits the addresses a key may come from, `command="…"` forces a single command, and `expiry-time` sets "a time after which the key will not be accepted". The manual notes the reason for `from`: without it, a stolen key "permits an intruder to log in from anywhere in the world."

## Why SSH keys outlive people

SSH keys are a classic source of [orphaned credentials](https://crunu.com/learn/orphaned-credentials):

- **They don't expire by default.** A public key in `authorized_keys` works until someone deletes the line.
- **They're scattered.** One person's key may sit on dozens of servers, under several system users, added by hand over years.
- **They're shared.** A team "deploy" key pair copied to several laptops is a [shared credential](https://crunu.com/learn/shared-credentials).
- **The private key travels.** It is on every laptop and backup the person used.

## Common mistakes

- **No passphrase.** A private key without one is usable by anyone who copies the file.
- **Removing the person from the Git host only.** Their key may still be in `authorized_keys` on servers.
- **One key everywhere.** A single key for personal GitHub, work servers and production means one loss opens all of them.
- **Not checking host fingerprints.** The first connection to a server asks you to accept its key; that is [trust on first use](https://crunu.com/learn/trust-on-first-use), and it only works if you actually compare.

## How Crunu relates to SSH keys

Crunu doesn't manage SSH access. It doesn't add or remove keys on servers or at Git hosts, and at offboarding you remove a person's public keys yourself.

It can hold key material you need in more than one place. Each member has a personal project with an environment called **my keys** for their own files. Note one deliberate limit: `crunu pull` refuses to write into `~/.ssh/`, along with shell startup files and other places where a file could change how you sign in or run code. You can allow a protected path for a single run with `--allow-path`, and the permission isn't remembered.

When someone leaves, SSH keys belong on your checklist next to tokens and API keys. [What to rotate when a developer leaves](https://crunu.com/guides/developer-offboarding-secret-rotation) lists where they hide, and repository-scoped SSH keys have their own page: [deploy key](https://crunu.com/learn/deploy-key). Steps for replacing SSH keys are in the [SSH rotation guide](https://crunu.com/rotate/ssh).

## Sources

- [OpenBSD manual: sshd(8), AUTHORIZED_KEYS FILE FORMAT](https://man.openbsd.org/sshd.8), checked October 30, 2026.