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.

Keep the identifier stable by policy and constraints. Generation, stored-value validity, business rules, references and access decisions are separate.

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.

Foreign keys do not automatically create an index on the referencing column. The users primary key supports checking whether a customer exists, but finding that customer’s orders is a separate access path. Consider an orders.user_id index for actual joins and parent updates or deletes; do not infer that declaring REFERENCES already provided it.

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 SQL results come from historical PostgreSQL 18.6 single-user checks, not a fresh execution. The psql variable was replaced by its observed value one; client-side gset behavior was not tested. 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-10-15.
PostgreSQL constraints, primary keys and referential integrity, checked 2026-10-15.
PostgreSQL sequence functions, nontransactional allocation and gaps, checked 2026-10-15.

ssh-agent remembers your decrypted keys while you work

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

An SSH agent provides signing operations for public-key authentication. For ordinary software keys, loading an encrypted private key unlocks material that the agent can then use without asking for the file passphrase on every connection. Clients receive public identities and signatures, not an exported private key through the normal agent protocol. Hardware-backed identities are different: the authenticator can retain the private key and require touch or verification.

The socket provides access to a service

OpenSSH normally discovers the agent through SSH_AUTH_SOCK, but IdentityAgent in client configuration can select a different socket or disable agent use. Knowing a pathname is not equivalent to having permission to connect. Socket and parent-directory permissions matter, while root and other processes running as the same user are important threats. Do not treat an environment variable itself as a secret that can replace operating-system isolation.

Agent access is also not an unconditional promise that every signing request succeeds. Key constraints, confirmation requirements, hardware presence, and protocol restrictions can refuse requests. Even a successful signature does not force a remote server to accept that key or grant access. Separate local signing capability from the server’s authorization decision.

Bound both the key and the delegation

ssh-add loads an identity, asking for its passphrase when needed. Other configured paths, such as AddKeysToAgent in ssh, can also load identities; ssh-add is not the only possible unlock path. The agent avoids repeatedly reading the encrypted key file, but does not guarantee that every copy of private material is absent from swap, dumps, backups, or other processes.

The -t option assigns a lifetime to an added identity. When that lifetime expires, the identity is removed; the option is not merely a reminder. The agent can supply a default lifetime; without either limit, an ordinary identity can remain until removed or the agent exits. Removing or replacing the disk file does not automatically replace a previously loaded copy.

The -c option requires confirmation through ssh-askpass. It is the helper’s successful exit status that approves use; a missing terminal on the remote host is not the determining test. Verify the local confirmation mechanism and reject unexpected requests. Confirmation reduces unattended use but does not replace understanding which host or operation a prompt represents.

Destination constraints, introduced in OpenSSH 8.9, further restrict allowed authentication paths using host keys. Forwarded use needs supporting clients and servers plus correct known-host data. A hostile hop can relay the socket again outside cooperating SSH, but signing remains limited to permitted destinations. These constraints are not a firewall; verify compatibility and keep OpenSSH patched.

When it breaks

Agent forwarding lets a remote host relay signing requests while the forwarding channel exists. An administrator or compromised process there may use that capability without extracting the private key. Prefer avoiding forwarding when it is unnecessary, and review the effective client configuration rather than assuming that omitting -A proves it is disabled.

Deleting an identity from the agent does not revoke a stolen private-key copy, remove a server’s authorized_keys entry, or necessarily terminate an already established SSH session. Conversely, removing server authorization can stop new logins while the agent still holds the key. A recovery plan must address each affected copy, authorization record, and active session separately.

Modern OpenSSH agents restrict remote provider loading and certain FIDO signatures; identifying remote clients relies on cooperating SSH forwarding. These safeguards reduce specific misuse, including using forwarded authenticators outside SSH. They are not a reason to expose the socket broadly or enable relaxed options without a reviewed need. Defaults and socket locations can vary across versions and platform integrations.

Socket access can delegate signing while private-key storage and server authorization remain separate. The retained fixture checks configuration selection only.

Check it quickly

Save as agent_config.py and run python3 agent_config.py with OpenSSH installed. The fixture creates a temporary configuration and evaluates it using ssh -G. It neither starts an agent nor reads a private key, opens a connection, changes an existing agent, or depends on a real socket. Its synthetic socket differs from the configuration. No example ran in this source review.

import os
from pathlib import Path
import subprocess
import tempfile

with tempfile.TemporaryDirectory(prefix='agent-config-') as directory:
 work = Path(directory)
 alternate = str(work / 'alternate.sock')
 config = work / 'config'
 config.write_text(f'''Host chosen-agent
 HostName example.invalid
 IdentityAgent {alternate}
Host no-agent
 HostName example.invalid
 IdentityAgent none
''')
 env = {'PATH': os.defpath, 'SSH_AUTH_SOCK': str(work / 'environment.sock')}
 for host, expected in [('chosen-agent', alternate), ('no-agent', 'none')]:
 result = subprocess.run(['ssh', '-G', '-F', str(config), host],
 env=env, cwd=work, text=True, capture_output=True, check=True)
 fields = dict(line.split(' ', 1) for line in result.stdout.splitlines())
 if fields.get('identityagent') != expected:
 raise RuntimeError('unexpected IdentityAgent')
 print(host, 'identityagent=', fields['identityagent'])
 if (work / 'alternate.sock').exists() or (work / 'environment.sock').exists():
 raise RuntimeError('the fixture must not create an agent socket')
 print('PASS: explicit socket overrides environment; none disables agent use')

The first result selects the explicit alternate socket despite SSH_AUTH_SOCK. The second selects none. PASS confirms these configuration expectations only: ssh -G does not test socket access, signing, expiry, confirmation, or remote authentication. IdentityAgent none disables agent use for that invocation; it does not disable authentication using files or other mechanisms.

In a separate authorized test session, inspect loaded fingerprints and test lifetime and confirmation with a disposable identity. Do not run ssh-add -D against a shared everyday agent merely to reproduce an article: it removes all loaded identities and can interrupt other work. Keep the observation exercise separate from changes to credentials or live sessions.

Sources

OpenBSD: ssh-agent, signing service, socket access, provider and FIDO restrictions, checked 2026-10-15.
OpenBSD: ssh-add, lifetime, confirmation, removal, and destination constraints, checked 2026-10-15.
OpenBSD: ssh_config, IdentityAgent, AddKeysToAgent, and forwarding configuration, checked 2026-10-15.
OpenSSH: agent restriction, host-key binding and forwarding compatibility, checked 2026-10-15.