Securing data with encryption

SSH, and the two sets of keys

A server has HOST keys in /etc/ssh, and they are what lets a client know it is talking to the same machine as last time; the client records what it saw in ~/.ssh/known_hosts, which is why replacing a server produces a loud warning about a changed key. A user has their OWN key pair, made with ssh-keygen: the private half stays in ~/.ssh/id_rsa or id_ed25519 and never leaves the machine, and the public half is copied into ~/.ssh/authorized_keys on the server — ssh-copy-id does exactly that.

Permissions are enforced rather than advisory, and this is where key-based login most often fails silently. sshd refuses to read a private key or an authorized_keys file that anyone else can get at, so the fix is always the same two commands: chmod 700 ~/.ssh and chmod 600 ~/.ssh/authorized_keys, with both owned by the user they belong to. A home directory that is group-writable will do it too. The refusal is not reported to the client — it simply falls back to asking for a password — so "the key is installed and it still prompts" is a permissions question every time, and the server's log is where it says so.

A passphrase on the private key means typing it each time, which ssh-agent solves by holding the decrypted key in memory for the session. ssh-add with no arguments loads the default keys from ~/.ssh — id_rsa, id_ecdsa, id_ed25519 — and ssh-add -l lists what the agent is holding. The agent is reached through the socket named in SSH_AUTH_SOCK, and agent forwarding lets a further hop use the same agent without the key ever being copied to the intermediate machine.

Beyond logins, ssh -L forwards a local port through the encrypted connection to somewhere the server can reach, and ssh -R does the reverse. That is the standard answer whenever a question describes reaching a service that is not exposed directly.

GPG

GPG uses the same public-key idea for files and messages. You encrypt with the recipient's PUBLIC key so that only their private key can open it, and you SIGN with your own private key so that anyone with your public key can verify it was you — those two directions are the thing to get straight, because every question here is built on candidates reversing them.

The commands: gpg --gen-key creates a pair, gpg --list-keys and --list-secret-keys show what you hold, gpg --export and --import move public keys about, and gpg --encrypt/--decrypt and --sign/--verify do the work. Keys live under ~/.gnupg. Note the name: the current release installs as both gpg and gpg2, and older systems that still shipped GnuPG 1.x kept gpg for it and used gpg2 for the newer one — so gpg2 and gpg are interchangeable in an answer unless the question is specifically about a machine with both.

Since GnuPG 2 the private keys are not handled by gpg itself. Every decryption and every signature goes through gpg-agent, which holds the unlocked key material and is why signing several files in a row asks for the passphrase only the first time. It expires a cached passphrase after default-cache-ttl seconds of disuse, up to max-cache-ttl, both set in ~/.gnupg/gpg-agent.conf, and the agent has to be told to re-read that file — gpgconf --reload gpg-agent. It is exactly the relationship ssh-agent has to the SSH client, and gpg-agent can take over that job too when configured with enable-ssh-support. Its two neighbours are worth naming so they are not mistaken for it: dirmngr is the component that does network access, such as keyserver lookups, and never sees a passphrase, and gpgconf inspects and restarts the components while storing no secrets of its own. Everything under ~/.gnupg, keyrings and the private key directory alike, should be mode 700 and owned by the user.

Revocation matters as much as generation, and it is the one thing that has to be done BEFORE you need it: once a private key is lost, nothing can be signed with it, including the statement that it should no longer be trusted. So a revocation certificate is generated at the same time as the key and kept somewhere safe. gpg --gen-revoke KEYID produces one — spelled --generate-revocation in current releases, with the short form still accepted — and -o writes it to a file. Publishing that certificate to a keyserver with gpg --send-keys is what withdraws the key in public.

$ gpg --list-secret-keys --keyid-format shortsec   ed25519/A1B2C3D4 2026-08-03 [SC]uid   Alice Doe <alice@example.com>$ gpg2 --gen-revoke -o revoke.asc A1B2C3D4Create a revocation certificate for this key? (y/N) y# store revoke.asc somewhere the key is not