Key login fails and a sudo rule grants root through a writable script
A small CI jump host runs Ubuntu 24.04 with OpenSSH 9.6. sshd_config contains PasswordAuthentication yes, KbdInteractiveAuthentication yes, PubkeyAuthentication yes, PermitRootLogin prohibit-password, AllowUsers alice deploy, and AuthorizedKeysFile .ssh/authorized_keys. Alice can log in with her key. Deploy's key is rejected with Permission denied (publickey), even though the same key works on another host and /home/deploy/.ssh/authorized_keys contains the exact public key. namei -l /home/deploy/.ssh/authorized_keys shows /home/deploy mode 0777, .ssh mode 0775, and authorized_keys mode 0666. For CI, /etc/sudoers.d/deploy contains deploy ALL=(root) NOPASSWD: /usr/local/bin/publish.sh; publish.sh is owned deploy:deploy and mode 0775 because deploy edits it. The team wants key-only SSH for alice, deploy limited to the CI subnet 198.51.100.0/24, and no interactive root shell. CI must keep publishing.
1. Diagnose deploy's public key rejection. State the exact ownership and mode requirements and the sshd setting involved, and give the log command and lines you would use to confirm.
Read the worked answer
sshd has StrictModes yes by default. It refuses to use a key file or directory that is writable by group or others, or whose ownership is not the user (or root for some paths). /home/deploy at 0777 and authorized_keys at 0666 are both unsafe, so sshd silently skips the key and offers only methods that are disabled or unavailable. Fix ownership and modes:
sudo chown -R deploy:deploy /home/deploy
sudo chmod 755 /home/deploy
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
Also check that .ssh and the key are owned by deploy and not by root; root ownership of authorized_keys is generally not accepted for a user's file unless StrictModes is off. Confirm with sshd -T | grep -i strictmodes, namei -l, and the server log: journalctl -u ssh --since '10 min ago' or /var/log/auth.log, looking for Authentication refused: bad ownership or modes for directory /home/deploy or ... file /home/deploy/.ssh/authorized_keys. Client-side ssh -vvv will show the key offered but not accepted. After fixing, retry before changing anything else.
2. Explain the privilege escalation in the sudo rule and give a concrete repair that preserves CI. Include why NOPASSWD is not the main problem.
Read the worked answer
The dangerous part is not NOPASSWD by itself; it is that deploy can modify the exact file that sudo runs as root. deploy can write /usr/local/bin/publish.sh, so sudo /usr/local/bin/publish.sh is equivalent to arbitrary root code execution. The sudoers line only fixes the path, and sudo does not hash or verify the file's contents. Repair:
sudo chown root:deploy /usr/local/bin/publish.sh
sudo chmod 0750 /usr/local/bin/publish.sh
Then deploy can execute but not edit it. CI changes should arrive through a reviewed repository or a root-owned deployment process, not through deploy's editor. Keep the sudoers entry but validate it with visudo -cf /etc/sudoers.d/deploy and inspect sudo -l -U deploy. If arguments are needed, allow a fixed argument list only if the script validates them; do not use wildcards. Consider a root-owned wrapper or a systemd service with a fixed ExecStart so the privileged interface is narrow. NOEXEC is not a reliable fix, and NOPASSWD is acceptable for automation once the target is root-controlled.
3. Propose sshd hardening that enforces key-only auth for alice from anywhere and deploy only from 198.51.100.0/24, and explain how sshd evaluates Match blocks. Give validation commands before reload.
Read the worked answer
Key-only global settings:
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
PermitRootLogin no
MaxAuthTries 3
Then restrict deploy by source. If your OpenSSH accepts CIDR in AllowUsers, use:
AllowUsers alice [email protected]/24
and add a Match block for deploy to remove unneeded channels:
Match User deploy Address 198.51.100.0/24
AllowTcpForwarding no
AllowAgentForwarding no
X11Forwarding no
PermitTTY no
PermitTTY no is safe for noninteractive ssh deploy@host /usr/local/bin/publish.sh and for passwordless sudo, but test the CI command. sshd applies the first obtained value for most keywords; a Match block overrides a global only for keywords it sets, and Match all ends the conditional section. Validate before reload with sshd -t, then sshd -T -C user=alice,host=...,addr=... and sshd -T -C user=deploy,host=...,addr=... from allowed and disallowed addresses. Reload with systemctl reload ssh, keep an existing session open, and test both keys from a second terminal. If AllowUsers CIDR is not accepted by your build, enforce deploy's source in Match Address together with a PAM access.conf rule or a firewall, and confirm with sshd -T.