ipfs/kubo · critical

private key in config does not match id: %s != %s

Error message

private key in config does not match id: %s != %s

What it means

At node construction, Kubo derives the peer ID from the private key stored in the repo (Identity.PrivKey) and compares it with the PeerID configured/expected. If they differ, the identity is inconsistent and node construction aborts. This protects against a corrupted or mismatched repo where the key was replaced or the config PeerID field points to a different keypair.

Source

Thrown at core/node/identity.go:25

	"github.com/libp2p/go-libp2p/core/peer"
)

func PeerID(id peer.ID) func() peer.ID {
	return func() peer.ID {
		return id
	}
}

// PrivateKey loads the private key from config
func PrivateKey(sk crypto.PrivKey) func(id peer.ID) (crypto.PrivKey, error) {
	return func(id peer.ID) (crypto.PrivKey, error) {
		id2, err := peer.IDFromPrivateKey(sk)
		if err != nil {
			return nil, err
		}

		if id2 != id {
			return nil, fmt.Errorf("private key in config does not match id: %s != %s", id, id2)
		}
		return sk, nil
	}
}

View on GitHub (pinned to 329838acdf)

Solutions

1. Back up then re-init the repo (`ipfs init`) to generate a consistent identity — note this changes your peer ID unless the key is preserved
2. If you have the original key, restore Identity.PrivKey so it matches the expected peer ID (verify: the base58 peer ID equals `ipfs id`'s output from when the repo was healthy)
3. Run `ipfs repo fsck` / check the datastore for corruption and re-import your pins from a known-good backup

sk, err := crypto.UnmarshalPrivateKey(privKeyBytes)
if err != nil { return err }
id2, err := peer.IDFromPrivateKey(sk)
if err != nil { return err }
if id2.String() != expectedPeerID {
    return fmt.Errorf("config identity mismatch: key derives %s, expected %s", id2, expectedPeerID)
}

When it happens

Trigger: Starting the daemon when cfg.Identity.PrivKey decodes to a key whose peer.ID differs from the id passed in — e.g. Identity.Peering/identity fields edited by hand, key regenerated but stale references kept, or a repo copied with mismatched config.

Common situations: Hand-editing the config's PrivKey or copying an init'ed repo and editing fields; restoring partial backups; migrations or repo corruption; tooling that regenerated the key but kept old config.

Related errors

• cannot set Identity.PeerID to a value that does not match th
• failed to get PrivKey
• unrecognized key type: %s
• private key in config was not a string
• failed to decode PrivKey: %w

AI-assisted analysis of ipfs/kubo@329838acdf (2026-09-03). Data as JSON: /api/errors/23cdfd97f5c77a15. Report an issue: GitHub.