chmod authorized_keys after every rewrite, so revoking a key does not disable the file

grep -v > tmp && mv keeps the temp file's umask mode, so an offboard left authorized_keys 0666 and sshd StrictModes silently refused every key in it — including the one the next onboard installs.
This commit is contained in:
Gmer4Lfe
2026-08-17 11:06:56 -04:00
parent 60e87ba518
commit fb49eb20e8
2 changed files with 13 additions and 2 deletions
+9 -1
View File
@@ -467,6 +467,7 @@ do_ssh_key_revocation() {
"grep -v '${our_comment}' /root/.ssh/authorized_keys \
> /root/.ssh/authorized_keys.tmp 2>/dev/null \
&& mv /root/.ssh/authorized_keys.tmp /root/.ssh/authorized_keys \
&& chmod 600 /root/.ssh/authorized_keys \
&& echo removed" 2>/dev/null | grep -q removed; then
echo "Our pubkey revoked from $REMOTE_SERVER_NAME"
SSH_REVOKE_REMOTE_OK=true
@@ -490,9 +491,16 @@ do_ssh_key_revocation() {
SSH_REVOKE_LOCAL_OK=true
elif [[ -f /root/.ssh/authorized_keys ]]; then
if grep -q "@${REMOTE_SERVER_NAME}" /root/.ssh/authorized_keys 2>/dev/null; then
# chmod after the mv, every time. `>` creates the temp file under the shell's umask
# and `mv` keeps the NEW file's mode, so this rewrite left authorized_keys 0666 on a
# filesystem that permits it. sshd's StrictModes then refuses every key in it without
# saying so to the client — the key is present, byte-correct, and inert, and the next
# onboard's SSH step fails with nothing in any Varaverk log to explain it. Only
# /var/log/syslog knows: "Authentication refused: bad ownership or modes".
if grep -v "@${REMOTE_SERVER_NAME}" /root/.ssh/authorized_keys \
> /root/.ssh/authorized_keys.tmp 2>/dev/null && \
mv /root/.ssh/authorized_keys.tmp /root/.ssh/authorized_keys; then
mv /root/.ssh/authorized_keys.tmp /root/.ssh/authorized_keys && \
chmod 600 /root/.ssh/authorized_keys; then
echo "$REMOTE_SERVER_NAME pubkey revoked locally ✅"
SSH_REVOKE_LOCAL_OK=true
else