The shared system user module defined a single hardcoded SSH authorized key and applied it to users.users.${username} for whatever user a host declared. The same key was also defined a second time in the sshd hardening module. As a result:
Every account authorized that one key regardless of the account's real owner — e.g. the emmathorpe account on the WSL host authorized lyrathorpe@Lyra-MBA.
On hosts importing the sshd module the key was listed twice, producing a duplicate authorized_keys entry.
Impact
Cross-user SSH access that does not reflect the account's owner. Latent on hosts without sshd, but incorrect everywhere keys are materialized.
Resolution
Authorized keys now come from the per-user identity registry (users/registry.nix), applied once by modules/users.nix; the sshd module no longer defines keys. Each account authorizes only its own key(s). Fixed by the user-registry refactor.
## Problem
The shared system user module defined a single hardcoded SSH authorized key and applied it to `users.users.${username}` for whatever user a host declared. The same key was also defined a second time in the sshd hardening module. As a result:
- Every account authorized that one key regardless of the account's real owner — e.g. the `emmathorpe` account on the WSL host authorized `lyrathorpe@Lyra-MBA`.
- On hosts importing the sshd module the key was listed twice, producing a duplicate `authorized_keys` entry.
## Impact
Cross-user SSH access that does not reflect the account's owner. Latent on hosts without sshd, but incorrect everywhere keys are materialized.
## Resolution
Authorized keys now come from the per-user identity registry (`users/registry.nix`), applied once by `modules/users.nix`; the sshd module no longer defines keys. Each account authorizes only its own key(s). Fixed by the user-registry refactor.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
The shared system user module defined a single hardcoded SSH authorized key and applied it to
users.users.${username}for whatever user a host declared. The same key was also defined a second time in the sshd hardening module. As a result:emmathorpeaccount on the WSL host authorizedlyrathorpe@Lyra-MBA.authorized_keysentry.Impact
Cross-user SSH access that does not reflect the account's owner. Latent on hosts without sshd, but incorrect everywhere keys are materialized.
Resolution
Authorized keys now come from the per-user identity registry (
users/registry.nix), applied once bymodules/users.nix; the sshd module no longer defines keys. Each account authorizes only its own key(s). Fixed by the user-registry refactor.