Key · XB Field Notes

A surrogate key keeps identity apart from meaning

Wed, 02 Feb 2028 00:00:00 +0000

A surrogate primary key separates row identity from a business value that can change. A customer’s email can be corrected while orders continue referencing the same customer identifier. This is useful when the business name is mutable or wide, but stability comes from schema and application policy. A generated number is not automatically immutable, secret, globally unique, or an authorization decision.

Generate identity and enforce uniqueness

PostgreSQL identity columns obtain default values from an associated sequence. GENERATED ALWAYS AS IDENTITY rejects ordinary explicit values, while GENERATED BY DEFAULT allows them. ALWAYS still permits an explicit OVERRIDING SYSTEM VALUE import. Neither form alone guarantees uniqueness; declare a PRIMARY KEY or UNIQUE constraint when duplicate identifiers must be rejected.

The primary key combines uniqueness with non-nullability and provides an index usable by references. Identity controls generation, while the constraint controls which stored values are legal. Keeping these responsibilities distinct matters during imports: a manually supplied value can collide with future generated values if the sequence is not reconciled. The sequence is not automatically advanced merely because a large identifier was inserted explicitly.

Preserve the business rule separately

A surrogate id does not stop duplicate business entities. If email is the unique login identifier, retain an explicit uniqueness constraint and decide the normalization rule. A plain text UNIQUE constraint follows the column’s comparison semantics; it does not silently implement the application’s desired case folding, whitespace handling, or mailbox rules. Make those decisions before migrating existing data.

Likewise, child tables need actual foreign keys if dangling references must be prevented. Renaming a non-key email leaves those references unchanged because they point to the id. This reduces the scope of that edit, but does not promise that every business rename becomes trivial: search indexes, audit records, external integrations, and cache invalidation may still depend on the changed value.

When it breaks

Treating sequence values as creation or commit order produces incorrect results under concurrency. Transactions can allocate numbers and commit in a different order, and aborted statements can leave gaps. Use an explicit timestamp and a deterministic tie-breaker for display ordering. A sequential identifier is also guessable; authorization must check the requesting principal and resource, even when a separate opaque public identifier is used.

Imports create another trap. Overriding identity generation can insert an id far ahead of the sequence without moving its current position. Eventually a generated insert may hit an existing primary key. Reconcile sequence state as part of a controlled import procedure, with concurrent writers excluded or otherwise coordinated. max(id) in an unrelated session is not a concurrency-safe allocation algorithm.

A migration can also remove the old natural-key constraint by accident. Audit duplicates and nulls before changing keys, retain required business uniqueness, and update every real reference. Do not add a surrogate solely because it is fashionable: a stable natural key may already express the intended contract without another column and index.

Check it quickly

Save this as identity.sql and run psql -X -v ON_ERROR_STOP=1 -f identity.sql in a disposable PostgreSQL 18 database. The experiment uses temporary tables and a final rollback, with no dependency on an existing users table.

\set ON_ERROR_STOP on
BEGIN;
CREATE TEMP TABLE users (
 id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
 email text NOT NULL UNIQUE
);
CREATE TEMP TABLE orders (
 id integer PRIMARY KEY,
 user_id bigint NOT NULL REFERENCES users(id)
);
INSERT INTO users(email) VALUES ('a@example.test') RETURNING id AS owner_id \gset
INSERT INTO orders VALUES (1, :owner_id);
UPDATE users SET email='renamed@example.test' WHERE id=:owner_id;
SELECT u.id, u.email FROM orders o JOIN users u ON u.id=o.user_id;
DO $$ BEGIN
 INSERT INTO users(email) VALUES ('renamed@example.test');
 RAISE EXCEPTION 'duplicate email accepted';
EXCEPTION WHEN unique_violation THEN RAISE NOTICE 'duplicate email rejected';
END $$;
DO $$ BEGIN
 INSERT INTO users(id,email) VALUES (99,'manual@example.test');
 RAISE EXCEPTION 'explicit identity accepted without override';
EXCEPTION WHEN generated_always THEN RAISE NOTICE 'explicit identity rejected';
END $$;
INSERT INTO users(id,email) OVERRIDING SYSTEM VALUE VALUES (100,'import@example.test');
INSERT INTO users(email) VALUES ('next@example.test') RETURNING id;
DO $$ BEGIN
 IF (SELECT email FROM users u JOIN orders o ON u.id=o.user_id)
 IS DISTINCT FROM 'renamed@example.test' THEN
 RAISE EXCEPTION 'rename broke the reference';
 END IF;
 IF (SELECT id FROM users WHERE email='next@example.test') IS DISTINCT FROM 3 THEN
 RAISE EXCEPTION 'unexpected identity sequence position';
 END IF;
END $$;
ROLLBACK;

The order still resolves to user one after the email changes. A duplicate email is rejected, and that failed insert consumes sequence value two. An explicit id without an override is rejected. The controlled override inserts id one hundred, but the following generated row receives id three, demonstrating that the import did not reposition the sequence. Assertions check the surviving reference and exact sequence result for this isolated fixture.

These results were verified on PostgreSQL 18.6. The final rollback removes the test objects; it does not establish gap-free sequence behavior for ordinary application transactions. The example demonstrates why generation, primary-key enforcement, foreign-key integrity, business uniqueness, and access control need separate reasoning even when they all involve one identifier.

Sources

PostgreSQL identity columns, generation modes and uniqueness limits, checked 2026-09-10.
PostgreSQL constraints, primary keys and referential integrity, checked 2026-09-10.
PostgreSQL sequence functions, nontransactional allocation and gaps, checked 2026-09-10.

ssh-agent remembers your decrypted keys while you work

Sat, 27 Feb 2027 00:00:00 +0000

An ssh-agent is a program that holds private keys for public key authentication and answers signing requests on their behalf. ssh finds it through SSH_AUTH_SOCK, the path of a Unix-domain socket, so the key is unlocked once and then borrowed by every connection that follows. The private key itself is never handed to a client.

That is a genuine security property and a genuine liability in the same move. The key never sits on disk in decrypted form, but the agent is a live oracle: anything that can reach the socket can sign, for as long as the identity stays loaded.

The socket is the capability

The agent protocol has no verb that exports a key. Asking for identities (message 11) returns message 12 with a public key blob and a comment — 51 bytes in the run behind this note, never private material. Asking it to sign an arbitrary challenge (message 13) returns message 14 with an 88-byte Ed25519 signature. An undefined opcode (99) comes back as message 5, SSH_AGENT_FAILURE. Renaming the private key file away did not stop the next signature, which is the point: the material lives in the agent’s memory.

That memory is protected by file permissions on the socket, and by nothing stronger. The socket is a Unix socket, mode 0600, owned by the uid that started the agent. A third process launched with nothing but SSH_AUTH_SOCK in its environment listed the identity and produced a signature without ever seeing the key file or the passphrase.

Unlock once, then bound the lifetime

ssh-add is the only step that needs the passphrase. It reads the key file, which should be mode 0600 — ssh-add ignores identity files readable by anyone else — and hands the decrypted identity to the agent. From then on the agent answers for you. ssh-add -t 8h sets a maximum lifetime, given in seconds or in the time format from sshd_config(5); in the run behind this note ssh-add -t 2 still listed the identity immediately afterwards and reported no identities three seconds later.

ssh-add -c goes further and demands confirmation for every use, routed through ssh-askpass. A signing request with no tty to answer the prompt was refused, which is exactly the behaviour you want when the request comes from a host that cannot reach your screen. Neither flag removes an identity; ssh-add -D deletes all of them, and killing the agent is the blunt version.

What the agent refuses to do

Modern ssh-agent narrows its own surface. By default it refuses signature requests for FIDO keys whose application string does not start with ssh: and whose data does not look like an SSH authentication request or an ssh-keygen signature — the default exists so that forwarding access to a hardware key does not also forward the ability to authenticate to websites. It also permits only local clients to load PKCS#11 or FIDO provider libraries unless allow-remote-pkcs11 is set.

ssh-add -h adds destination constraints, restricting a key to specific source and destination host pairs, and the whole connection path including forwarding is tested against them. That is a far better answer than hoping a bastion is trustworthy.

When it breaks

The classic failure is a leaked SSH_AUTH_SOCK. Any process with that one variable and the same uid holds the unlocked identity: no key file, no passphrase, no prompt. It presents as a key that keeps working after you rotate it on disk, because the agent still holds the old one. Revocation is the agent’s lifetime, so bound it with ssh-add -t and delete identities when the work is done.

The second failure is an agent that outlives the session that created it. An agent started at login with ssh-add and no lifetime keeps signing long after you have moved on, and on a shared machine its socket under $HOME/.ssh/agent/ is reachable by anything running as you. Rotating the key file does not help: the loaded copy stays valid until the agent dies or the identity is deleted.

Check it quickly

Confirm which socket you are talking to and what it holds:

echo "$SSH_AUTH_SOCK"
ls -l "$SSH_AUTH_SOCK"
ssh-add -l
ssh-add -t 8h ~/.ssh/id_ed25519
ssh-add -D

The listing should show one fingerprint per loaded identity and nothing else; printing nothing with exit status 1 means no identity is loaded. The ls -l line should show a socket with mode 0600 owned by you — anything world-accessible means another account can sign as you — and the final command should leave ssh-add -l reporting no identities at all.

Sources

OpenBSD: ssh-agent, holds private keys for public key authentication, socket location, and restrictions on remote clients, checked 2026-09-16.
OpenBSD: ssh-add, -t lifetime, -c confirmation, and -h destination constraints, checked 2026-09-16.
OpenBSD: ssh, SSH_AUTH_SOCK and the askpass environment variables, checked 2026-09-16.