The trailing field on an SSH public key is a free-text comment. It's purely a human-readable label — SSH ignores it cryptographically, so editing it never changes the key or breaks existing access.
A public key looks like this:
ssh-ed25519 AAAAC3Nz...example...not-a-real-key duncan@laptop
└─ type ──┘ └──────── key material ─────────┘ └── comment ──┘
- Identify the machine/purpose. When you paste keys into GitHub,
~/.ssh/authorized_keys, or a cloud console, the comment is often the only thing distinguishing one key from another. - Audit & cleanup. Months later you can answer "which key is this?" and safely remove keys for decommissioned laptops.
- No security cost. The comment isn't secret and isn't part of the signature — changing it is harmless.
Common conventions: user@hostname, a date, or a purpose string like
deploy-ci-2026 or alex@work-macbook.
Use -C to set the comment at generation time:
ssh-keygen -t ed25519 -C "alex@work-macbook" -f ~/.ssh/id_ed25519-t ed25519— modern, recommended key type.-C "..."— the comment.-f— output path (omit to accept the default).
The resulting ~/.ssh/id_ed25519.pub ends with your comment:
ssh-ed25519 AAAAC3Nz...example...not-a-real-key alex@work-macbook
You don't need to regenerate the key. -c rewrites the comment in place:
ssh-keygen -c -f ~/.ssh/id_ed25519 -C "alex@work-macbook (2026 rebuild)"- Operates on the key file pair; the key material is unchanged.
- If the private key is passphrase-protected, you'll be prompted for it.
- Keys already deployed to servers keep working — the comment is local metadata and doesn't have to match what's on the remote side.
Verify the new comment:
cat ~/.ssh/id_ed25519.pub- The comment runs to the end of the line, so spaces are fine — avoid newlines.
- All keys shown here are illustrative placeholders, not real keys.