8 Practical Age Encryption Commands for Linux

I stopped using GPG for everyday file encryption about two years ago. The replacement is age, a small tool by Filippo Valsorda that does one thing: encrypt files. No keyrings, no trust database, no config files, no twenty-page man page. If you want age encryption on Linux, you install one binary, generate a key, and you are done in under a minute. This guide walks through the eight commands I actually use, from key generation to encrypted backups.

Why Age Encryption Instead of GPG

GPG tries to be an email signer, a package verifier, a key server client, and a file encryptor at the same time. That flexibility is exactly why people get it wrong. A wrong flag can produce an unencrypted signed file when you wanted an encrypted one.

Age has no such foot-guns. It encrypts with X25519 keys or a passphrase, and that is the whole feature list. Keys are single lines of text you can paste into a password manager. The format is an open spec, so other implementations like rage (a Rust port) read the same files.

Installing age on Linux

The package sits in every major repo:

# Debian / Ubuntu
sudo apt install age

# Fedora
sudo dnf install age

# Arch
sudo pacman -S age

You get two binaries: age for encrypting and decrypting, and age-keygen for creating keys. The project lives at the age GitHub repository, where prebuilt binaries cover every platform Go compiles for.

1. Generate a Key Pair for Age Encryption

One command creates everything you need:

age-keygen -o ~/.config/age/key.txt

The output file holds your private key and prints the matching public key to the terminal:

Public key: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p

That public key is the recipient string. Share it anywhere. The private key file is the only thing you protect. I keep mine in a password manager entry and on an offline USB stick, nothing else.

2. Encrypt a File to a Recipient

Point age at a public key with -r and give it a file:

age -r age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p -o secrets.txt.age secrets.txt

The .age extension is a convention age encryption users stick to, not a requirement. The output is a compact binary format. Nobody without the matching private key can read it, including you if you lose the key file. There is no recovery path, which is the point.

3. Decrypt with Your Private Key

age -d -i ~/.config/age/key.txt -o secrets.txt secrets.txt.age

The -i flag names the identity file. Decryption is fast even on large files because age uses ChaCha20-Poly1305 in chunks, so it streams instead of loading everything into memory.

4. Age Encryption with Just a Passphrase

Sometimes a key pair is overkill. Sending a file to a person once, or stashing an archive you will open in five years, works better with a passphrase:

age -p -o backup.tar.gz.age backup.tar.gz

Age generates a strong passphrase suggestion if you leave the prompt empty, something like hospital-ancient-butter-rebel-quality-hip-purse. Take the suggestion. It comes from a proper wordlist and beats whatever you would invent under pressure.

Decryption with age -d detects the passphrase format automatically and prompts you. No flags needed.

5. Encrypt to Multiple Recipients

Repeat -r for each person who should be able to open the file:

age -r age1ql3z7h... -r age1xk2p9w... -o report.pdf.age report.pdf

Any single listed key decrypts the file. I use this for shared server credentials: my key plus a colleague’s key, so either of us can recover them without asking the other. Store team public keys in a plain text file in your repo, one per line, and pass it with -R keys.txt instead of stacking flags.

6. Use Your Existing SSH Keys

This is the age encryption feature that sold me. It works with the SSH keys you already have, no new key material required:

# Encrypt to someone's SSH public key
age -R ~/.ssh/id_ed25519.pub -o notes.md.age notes.md

# Decrypt with the private half
age -d -i ~/.ssh/id_ed25519 -o notes.md notes.md.age

Even better, GitHub exposes everyone’s SSH public keys at https://github.com/username.keys. You can encrypt a file to any GitHub user without ever exchanging keys:

curl -s https://github.com/torvalds.keys | age -R - -o kernel-notes.age kernel-notes.txt

7. Age Encryption for Tar Backups

Age reads stdin and writes stdout, so it slots into pipelines the way any Unix tool should:

tar czf - ~/documents | age -r age1ql3z7h... -o documents-$(date +%F).tar.gz.age

Restore reverses the pipe:

age -d -i ~/.config/age/key.txt documents-2026-08-20.tar.gz.age | tar xzf -

For scheduled backups this beats passphrase mode because the cron job only needs the public key. The private key never touches the backup machine. If you want deduplication and snapshots on top of encryption, a dedicated tool is the better fit, and I covered one in the restic backup guide. For moving encrypted archives between machines, croc pairs well with age output.

8. ASCII Armor for Text-Only Channels

The -a flag wraps output in PEM-style base64, safe to paste into a ticket, an email, or a chat message:

age -a -r age1ql3z7h... -o token.age token.txt
cat token.age

-----BEGIN AGE ENCRYPTED FILE-----
YWdlLWVuY3J5cHRpb24ub3JnL3YxCi0+IFgyNTUxOSBURi9NRXBl...
-----END AGE ENCRYPTED FILE-----

Armored files are about a third larger than binary output. Skip the flag when size matters.

When Not to Use Age Encryption

Age does not sign anything. If you need to prove who created a file, you want cosign or signify, not age. It also has no concept of key expiry or revocation. A leaked private key stays valid forever, so rotate keys by re-encrypting the files that matter.

And age protects files at rest, not secrets already leaked into your git history. Scan for those separately, which is what the gitleaks guide covers.

Wrapping Up

Eight age encryption commands cover practically everything: age-keygen once, then -r, -d -i, -p, -R, and -a as the situation demands. My rule of thumb after two years: passphrase mode for one-off archives, key pairs for anything automated, SSH recipients for sending files to other people.

The age format specification is short enough to read over coffee, which I cannot say about RFC 4880. That simplicity is why age encryption replaced GPG in my daily work, and why I expect it to stick around.