Skip to content

SSH Alias Fails on One Fleet Host — Service Account Squats the Standard User's UID

Every host in the fleet has a standard majorlinux user at uid 1000 for personal SSH access and Ansible. ssh <alias> works everywhere — except one host, where it fails with Permission denied (publickey) even though ssh root@<alias> works fine and the Tailscale alias itself resolves correctly.

Symptom

$ ssh majortoot
majorlinux@majortoot: Permission denied (publickey).
$ ssh root@majortoot
# works fine

This looks like a key rotation regression but isn't one — nothing rotated or broke. The account never existed on this host in the first place.

Root Cause

Check whether the user exists at all before assuming a key/ACL problem:

$ ssh root@<host> "getent passwd majorlinux"
# (no output — nothing found)
$ ssh root@<host> "cut -d: -f1,3 /etc/passwd | grep -v -E ':[0-9]{1,3}$'"
nobody:65534
mastodon:1000
ansible:1001

The host's primary application runs as a service account that claimed uid 1000 before the fleet's majorlinux convention was ever applied to this box — in this case a Mastodon instance, provisioned with mastodon as the first non-system user during initial setup, well before it joined the standard fleet build. When the box was later migrated (DigitalOcean → Hetzner) and brought under the same Tailscale/SSH conventions as the rest of the fleet, nobody went back to carve out a majorlinux user at a different uid — root access (with the usual personal-device keys pre-loaded into /root/.ssh/authorized_keys) was already sufficient for admin tasks, so it was never missed until a routine, non-root check (a mention-spam audit query) tried to use the alias like every other host.

sshd_config on the host was fine the whole time — PubkeyAuthentication yes, AuthorizedKeysFile .ssh/authorized_keys (defaults). There was no key, no ACL, and no config to fix. There was just no account to authenticate as.

Diagnosis Checklist

  1. ssh <alias> fails, ssh root@<alias> works → auth for root is fine, so this isn't a Tailscale/MagicDNS/host-key problem (see tailscale-ssh-magicdns-vs-pinned-ip-after-migration for those failure modes).
  2. ssh root@<alias> "getent passwd majorlinux" → empty output confirms the account doesn't exist, rather than existing-but-locked-out.
  3. cut -d: -f1,3 /etc/passwd | grep -v -E ':[0-9]{1,3}$' → lists every non-system account and its uid. If the box's main service (database, mail, federation app, etc.) owns uid 1000, that's very likely why the fleet-standard user was never created here.
  4. Check /root/.ssh/authorized_keys — if the personal-device keys are already trusted there, root access has quietly been "good enough" and the gap just never surfaced.

The Fix (Two Options)

Leave it root-only (cheapest, what we did here): update the host's server doc to say ssh root@<alias> explicitly, and note why the standard user doesn't exist so a future session doesn't re-diagnose the same thing as a regression.

Create a non-root majorlinux user at a free uid (e.g. 1002) if you want least-privilege access for routine checks (cron-style audits, log tailing) without using root every time. Match it to the fleet's existing sudo/group conventions and drop the new key into its ~/.ssh/authorized_keys rather than root's.

Takeaway

Before treating an SSH auth failure on one fleet host as a regression, check whether the account exists at all (getent passwd <user>) — don't assume every host got the same base-user layout just because they're all on the same Tailscale/Ansible conventions today. A host that predates the convention, or that has a service account competing for the same uid, can legitimately never have had the "standard" user in the first place.