Private Key Here, Public Key There: WireGuard Keys
Your private key stays on your device; the peer entry holds the other side's public key. Share only the public half, and give each device its own identity.
Most hand-built WireGuard failures come down to which key went where. The interface section carries the private key of the device you are configuring, while a peer section carries the public key of the machine at the other end. Swapping those halves, or pasting the wrong one, produces a handshake that never completes and a log that never names a key. Work the four checks below in order before touching AllowedIPs or DNS.
Two Keys, Two Directions
A private key belongs to exactly one device and stays in that device's interface section. Its public half is what every other peer needs in order to recognise the device, and the tooling derives it rather than inventing it. On the server, your device's public key appears as a peer entry; on your device, the server's public key holds that role. Reading a config aloud in those terms catches most mix-ups before they reach a handshake.
The wg command prints what the local interface is actually using, including both public keys. That makes it the fastest way to separate a configuration mistake from a connectivity one:
wg show
wg show interfacesThe first output lists each peer with its public key, the endpoint it last used, and the age of its last handshake. A handshake age of never on one side and a recent one on the other points at a key that only one end accepted. The second command names the interfaces you can inspect further.
What to Share and What Never to Share
A public key is meant to be handed over, though it still identifies a device relationship, which is why sending it to the administrator who asked differs from publishing it. A private key never leaves the device that generated it. An exported profile or a QR code holds the whole configuration including that private key, so neither is safe to pass around, and hiding the text inside an image changes nothing. Preshared keys are optional and equally secret, and both ends must carry the same value or the handshake stops at that stage.
One more distinction is worth stating plainly: an endpoint is an address and a port, never a key. Pasting a public key into the endpoint field, or an address into a key field, produces a profile that parses and then does nothing. The tooling will not catch it, because both fields are just strings. The WireGuard quickstart shows the generate-and-derive pipeline in one line.
One Device, One Peer Entry
Where the service allows it, every device should carry its own peer identity. Pasting a laptop's complete profile onto a phone blurs which device holds that identity on the server and makes revoking one lost handset harder. If a private key leaks, remove the old peer authorisation on the server and provision a replacement. Deleting the local file does not remove the server's entry, and a fresh client key helps nobody until the server knows its public half.
Keep the mapping of device to public key next to the address list. That list is what turns a revocation into a two-minute task rather than an afternoon.
What Still Fails After the Handshake
Key pairs identify peers; they do not decide network behaviour. AllowedIPs associates address ranges with a peer, and the client or setup tool manages the routes around it. The symptom usually says which layer to open next:
| What you see | Which key problem it usually means | Where to look first |
|---|---|---|
| Handshake age stays at never on both ends | Peer public key missing, or an endpoint pointing at nothing | wg show, then the endpoint value |
| Handshake completes on one side only | The two ends hold different public keys for each other | wg show on both hosts |
| Handshake works, then no traffic | AllowedIPs or routes rather than keys | wg show and the route table |
| Worked until a key was regenerated | The peer entry still holds the old public key | Compare both public keys, then update the peer |
DNS can fail after both peers authenticate correctly, and an application can fail while the tunnel itself is healthy, so a working handshake is not the end of the diagnosis. Keys also say nothing about an operator's logging practice or about whether a website recognises your account, and those questions belong elsewhere. Move to the network layers once the four checks pass, because a missing key is not a routing problem in disguise.