WireGuard Preshared Key: What It Adds, and Why It Is Not a Password

Affiliate disclosure - This post contains Contabo affiliate links. If you grab a VPS through them, we earn a commission at no extra cost to you.

Every WireGuard peer already has a key pair, so the first reasonable question about PresharedKey is what a third key is supposed to add.

The answer is narrow and specific, and it is worth stating precisely, because the two common descriptions of it are both wrong.

What it is not

It is not a password on the tunnel. People add it expecting the connection to require a secret in the way SSH requires a passphrase. That is not the shape of it.

It is not a replacement for anything. Adding a preshared key does not let you use weaker keys, skip firewall rules, or expose the port more safely.

What it is

WireGuard's handshake derives session keys from the two peers' public and private keys. If a preshared key is configured, it is mixed into that derivation as an additional input.

The consequence is the whole point: the preshared key is symmetric and never sent over the wire. An attacker who records every packet of your traffic today, and who later acquires the ability to break the elliptic curve exchange, still cannot derive the session keys, because one of the inputs never crossed the network.

The WireGuard documentation describes this as post quantum resistance, and that phrasing is accurate as long as you keep the threat model in view. The adversary being defended against is one who stores traffic now and decrypts it later. If nobody is recording your tunnel, this defends against nothing, and it still costs you almost nothing to add.

Generating and installing one

wg genpsk

That prints a base64 encoded 32 byte key. To generate and store it in one step:

wg genpsk > peer1.psk
chmod 600 peer1.psk

It goes in the [Peer] section, on both machines, with the same value:

[Peer]
PublicKey = <the other side's public key>
PresharedKey = <the same value on both ends>
AllowedIPs = 10.10.0.2/32

One preshared key per peer pair, not one per server. Reusing a single value across every client means any one of them holds the key that protects all the others.

Adding one to a live tunnel without locking yourself out

This is where people get stung. A preshared key that matches on only one side means the handshake stops completing, and WireGuard does not tell you why. wg show reports no recent handshake, the same output you get from a wrong port, a firewall drop, or a bad public key.

If the tunnel is your only route to a remote server, that is a lockout.

The safe order:

1. Generate the key and get it onto both machines first, without editing either config.
2. If you have out of band access, a console or IPMI, use it and edit both sides.
3. If you do not, schedule a revert. Something like echo "wg-quick down wg0 && wg-quick up wg0" | at now + 10 minutes with the original config on disk, so a mistake fixes itself while you still have a way in.
4. Edit the remote side, then the local side, then confirm with wg show that a handshake occurred within the last two minutes.

The general symptom, a tunnel that used to work and now shows no handshake, is covered in handshake troubleshooting. Add "one side has a preshared key and the other does not" to that list.

Where preshared keys sit against everything else

They do nothing for the visibility of the tunnel. A network that blocks WireGuard by traffic shape blocks it just the same. That is a different problem with different answers: see anti DPI VPN bypass.

They do nothing about who can reach the port. Hiding the endpoint is a separate technique, covered in port knocking and stealth.

They should be treated as key material. Not in a chat message, not in a shared document, not committed to a repository. A preshared key in a git history is worse than no preshared key, because it produces confidence that is not backed by anything.

If you are building the server side from scratch, the full walkthrough is in self-hosting WireGuard on a VPS, and adding clients later is covered in adding a WireGuard peer.