Generate a WireGuard Key Pair Locally: Commands and Care

Two commands generate a WireGuard key pair and both arrive with the standard tools, so nothing about this task needs a website that offers to make a key for you. What goes wrong is never the curve arithmetic; it is the permission bits, the place the file lands, and what gets sent to the far end afterwards. The sequence below starts in an empty directory and ends at a peer that carries traffic. Read it once before running it, because the first line only matters if the next one runs in the same shell.

Generating the pair in one shell

The documented workflow restricts file creation before the private value exists, then derives the public value from it. All three lines belong together in a single shell session:

umask 077  # applies to files created next, so keep the next line in this shell
wg genkey | tee privatekey | wg pubkey > publickey
wg pubkey < privatekey  # re-derive and compare with publickey

wg genkey writes a 32-byte Curve25519 private key in base64; wg pubkey reads it and derives the matching public key, and tee saves the private value while passing it down the pipe. That order is why the permission line comes first, and why pasting the pipeline into a second terminal quietly loses it. The filenames are illustrative, and what matters is that both files land somewhere the owning device controls. If a private file already exists with default permissions, chmod 600 privatekey fixes the current file and does nothing about copies made earlier.

Keeping the private half on one device

The private value belongs on the machine that will own the identity, in a directory that machine protects and its backups treat as a credential. It does not belong in a shared folder, in a message to yourself, or in a snippet attached to a support ticket, and an embedded copy makes the configuration file exactly as sensitive as the key. A key that has lived in three places cannot be reasoned about later, which is the practical reason for keeping it in one.

Destroying a retired file deliberately is part of the same habit. Leaving it in a downloads folder until someone notices is not.

What the peer operator needs from you

The other side needs the public value and the address arrangement its operator has chosen, nothing else. Send that public string through whatever channel the operator expects, then confirm which peer entry it was attached to before anyone tests it, because a correct key in the wrong stanza fails in a way that looks like a key problem. Send it as a single unwrapped line, since a key broken across two lines pastes back into a configuration file without complaint and then never matches.

Generating a key authorises nothing by itself. The peer must be configured to accept it, and the configuration step belongs to whoever runs that end.

Testing the pair with a real exchange

A key pair identifies one end of a tunnel; it creates no route, no resolver entry, no forwarding rule and no firewall allowance. After the peer is provisioned, test the exchange rather than the file: a handshake that appears in wg show, an address that answers inside the tunnel, and one application request that depends on the route. That trio separates a key that is wrong from a key that is fine and a path that is missing.

Keep one identity per device when the deployment allows it, so a lost unit can be revoked on its own instead of forcing everyone to re-key. That decision is also what makes the replacement procedure below safe to run.

Replacing a key without a gap

Generate the replacement on the device, add the new public key as an additional peer, confirm it carries traffic, and only then remove the old one. Doing it in that order means the tunnel never has a moment with no valid identity, and the rollback is simply deleting the entry you just added.

Keep the superseded private file until the new peer is confirmed, then destroy it on purpose. The WireGuard quickstart is the reference for the commands themselves, and it is short enough to read in full before you start.