New Developer Cannot Use Public Key on a Hardened Bastion

sshd returns a generic Permission denied (publickey) for every authentication failure - unknown user, disallowed user, bad key, rejected file permissions, and unreadable key file all look identical. That is deliberate anti-enumeration behaviour, so the diagnosis must come from the server side.

Test in this order, cheapest and most deterministic first:

1. Allowlist. AllowUsers deploy admin does not contain sam. Confirm with sshd -T | grep -i allowusers (allowlist is applied after key exchange, which matches the log line showing the connection got as far as authentication).
2. Ownership and mode. mv preserves the original owner, so authorized_keys is root:root. StrictModes requires the file and its directory to be owned by the user (or root) with no group or world write; a root-owned, sam-inaccessible .ssh is rejected. Check ls -ld /home/sam /home/sam/.ssh; ls -l /home/sam/.ssh.
3. SELinux label. A file moved from /tmp keeps user_tmp_t; sshd cannot read it and logs an AVC rather than a friendly message. Check ls -Z and ausearch -m avc -ts recent.
4. Only then key content: it may be a private key pasted by mistake, malformed, or for a different algorithm.

Remediation, in order:

• Add sam to the allowlist: edit AllowUsers deploy admin sam, then sudo sshd -t && sudo systemctl reload sshd (validate first - a syntax error plus a restart locks everyone out; reload keeps established sessions).
• Correct ownership and modes: sudo chown -R sam:sam /home/sam/.ssh, sudo chmod 700 /home/sam/.ssh, sudo chmod 600 /home/sam/.ssh/authorized_keys.
• Fix the label: sudo restorecon -Rv /home/sam/.ssh, then confirm ls -Z shows ssh_home_t on both entries and that ausearch -m avc -ts today | grep sshd produces nothing new.

StrictModes is not bureaucratic. If authorized_keys or its parent directory is writable by anyone other than the account owner or root, a second user could append their own key and authenticate as Sam, escalating from their account to his. The same reasoning makes a world-writable home directory (chmod 777) a privilege-escalation vector, not merely untidy. sshd therefore refuses to trust a key store it cannot prove is under the right principal's exclusive control - including the case where the file is root-owned and Sam cannot control it at all.

Reject it. Setting StrictModes no disables the control for every account on the host, not just Sam, and converts a single-user onboarding problem into a host-wide weakening. It also would not fully work: the SELinux label problem is independent of StrictModes, so sshd would still fail to read a user_tmp_t file, and the allowlist still excludes Sam. The admin would have loosened a control, still not fixed the login, and lost the evidence trail.

The correct 'immediate' fix is three commands: add sam to AllowUsers, chown the .ssh tree to sam, and restorecon. That is faster than editing sshd_config, validating, reloading, and later remembering to revert.

Structurally, onboarding should not be hand-typed. A configuration-management role or documented runbook that creates the account, installs the key with correct ownership via sudo -u sam install -d -m 700 ~sam/.ssh, sets the label, and adds the allowlist entry would have prevented all three faults. Also require the key to come through a reviewable channel rather than a paste from /tmp, and record every allowlist change in version control.