Skip to content
Create free account
Create free account
LearnSSH key

What is an SSH key?

Also known asSSH key pairauthorized_keys
Example. Kiteline is a fictional company.
On this page

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). 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.

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:

  • 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.
  • 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, 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 lists where they hide, and repository-scoped SSH keys have their own page: deploy key. Steps for replacing SSH keys are in the SSH rotation guide.

Sources

From the blog

  • Teams

    An offboarding checklist for engineering teams

    Removing an account takes seconds. Secrets outlive it. A practical checklist for engineering offboarding, from sessions and tokens to reissuing values.

    Offboarding guide

  • Servers

    Secrets in Docker images: build args, layers and checks

    ARG and ENV values stay in a Docker image, and deleting a file in a later layer doesn't remove it. How to build with secret mounts and check an image.

    Sharing .env files guide

  • Secrets

    source .env can run code: loading env files into a shell

    set -a; source .env runs the file as a shell script, so $(…) and backticks execute. Why shells and dotenv parsers disagree, and safer ways to load .env.

    Sharing .env files guide