Emergency Mitigation Guide: SSH ssh-keysign Host-Key Exposure Risk

Security advisory and mitigation guide for Linux systems. This guide is intended for administrators, hosting providers, workstation users, and anyone who needs an immediate defensive workaround while waiting for a vendor kernel update.

Emergency notice: A public proof-of-concept claims that vulnerable Linux systems may allow an unprivileged local user to read root-owned files, including SSH host private keys under

/etc/ssh/ssh_host_*_key

. Treat this as a local privilege boundary emergency until your Linux distribution ships and installs a fixed kernel.

Reference: Public PoC repository

Summary

The reported attack path targets

ssh-keysign

, a privileged OpenSSH helper related to host-based authentication. On affected systems, this may expose sensitive root-owned files such as SSH host private keys and potentially other files such as

/etc/shadow

.

This mitigation reduces the exposed attack surface by disabling

ssh-keysign

SUID execution, forcing OpenSSH host-based authentication off, and enforcing correct permissions on SSH host private keys.

Important: This is a mitigation, not the final fix. The definitive remediation is to install your distribution kernel update and reboot into the patched kernel.

What this mitigation does

1. Removes the SUID bit from ssh-keysign where present.
2. Disables OpenSSH host-based authentication globally.
3. Disables EnableSSHKeysign globally.
4. Fixes SSH host private key ownership and permissions.
5. Provides verification commands.
6. Explains when to rotate SSH host keys.

Immediate mitigation command

Run the following command as root or with

sudo

:

sudo sh -c '
set -eu

echo "[1/5] Disabling ssh-keysign SUID bit where present..."

for bin in \
    /usr/lib/openssh/ssh-keysign \
    /usr/lib/ssh/ssh-keysign \
    /usr/libexec/openssh/ssh-keysign \
    /usr/libexec/ssh/ssh-keysign
do
    if [ -e "$bin" ]; then
        echo "Found: $bin"
        chmod u-s "$bin" || true
    fi
done

echo "[2/5] Disabling host-based SSH authentication globally..."

install -d -m 0755 /etc/ssh/ssh_config.d

cat > /etc/ssh/ssh_config.d/99-disable-ssh-keysign.conf <<EOF
Host *
    EnableSSHKeysign no
    HostbasedAuthentication no
EOF

chmod 0644 /etc/ssh/ssh_config.d/99-disable-ssh-keysign.conf
chown root:root /etc/ssh/ssh_config.d/99-disable-ssh-keysign.conf

echo "[3/5] Fixing SSH host private key permissions..."

for key in /etc/ssh/ssh_host_*_key; do
    if [ -f "$key" ]; then
        chown root:root "$key"
        chmod 0600 "$key"
        echo "Protected: $key"
    fi
done

echo "[4/5] Checking ssh-keysign state..."

for bin in \
    /usr/lib/openssh/ssh-keysign \
    /usr/lib/ssh/ssh-keysign \
    /usr/libexec/openssh/ssh-keysign \
    /usr/libexec/ssh/ssh-keysign
do
    if [ -e "$bin" ]; then
        ls -l "$bin"
    fi
done

echo "[5/5] Done."
echo "Install your distribution kernel update as soon as possible, then reboot."
'

Optional stronger mitigation: restrict ptrace

On systems where debugging tools are not required, you may temporarily restrict same-user process inspection:

echo 'kernel.yama.ptrace_scope = 2' | sudo tee /etc/sysctl.d/99-restrict-ptrace.conf
sudo sysctl --system

Warning: This may break tools such as

gdb

,

strace

, profilers, IDE debuggers, crash collectors, and some monitoring tools. Use this only if you understand the operational impact.

Verification

Check that ssh-keysign is no longer SUID root

find /usr/lib /usr/libexec -name ssh-keysign -exec ls -l {} \; 2>/dev/null

Good example:

-rwxr-xr-x 1 root root ... /usr/lib/openssh/ssh-keysign

Risky example:

-rwsr-xr-x 1 root root ... /usr/lib/openssh/ssh-keysign

If you see

rws

in the owner permission field, the SUID bit is still enabled and should be removed unless you intentionally use host-based authentication.

Check the OpenSSH hardening file

cat /etc/ssh/ssh_config.d/99-disable-ssh-keysign.conf

Expected output:

Host *
    EnableSSHKeysign no
    HostbasedAuthentication no

Check SSH host private key permissions

sudo ls -l /etc/ssh/ssh_host_*_key

Expected pattern:

-rw------- 1 root root ... /etc/ssh/ssh_host_ed25519_key
-rw------- 1 root root ... /etc/ssh/ssh_host_ecdsa_key
-rw------- 1 root root ... /etc/ssh/ssh_host_rsa_key

Does this break normal SSH?

For most users, no. This mitigation disables OpenSSH host-based authentication, not normal SSH login.

Public-key authentication, password authentication, keyboard-interactive authentication, and normal

sshd

service operation should continue to work.

This may affect environments that intentionally use OpenSSH host-based authentication, such as old Unix clusters, legacy internal automation, or specialized infrastructure. Those environments should prioritize patching, key rotation, and migration to a safer authentication method.

Kernel update is still required

Apply your distribution kernel update as soon as it is available. After updating, reboot the system and confirm that the running kernel is the updated one.

Debian / Ubuntu

sudo apt update
sudo apt full-upgrade
sudo reboot

Fedora

sudo dnf upgrade --refresh
sudo reboot

RHEL / Rocky Linux / AlmaLinux / CentOS Stream

sudo dnf update
sudo reboot

Arch Linux

sudo pacman -Syu
sudo reboot

After reboot, verify the running kernel:

uname -a

When to rotate SSH host keys

Rotate SSH host keys if any of the following are true:

1. An untrusted local user had shell access before mitigation.
2. The machine is multi-user.
3. The proof-of-concept was run on the system.
4. Logs show suspicious repeated execution of ssh-keysign, chage, or unknown local binaries.
5. You cannot prove the system was not exposed.

Rotate SSH host keys

sudo mkdir -p /root/old-ssh-host-keys

sudo cp -a /etc/ssh/ssh_host_* /root/old-ssh-host-keys/

sudo rm -f /etc/ssh/ssh_host_*_key /etc/ssh/ssh_host_*_key.pub

sudo ssh-keygen -A

sudo systemctl restart ssh || sudo systemctl restart sshd

Record the new fingerprints

ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub

ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

Important: After rotating host keys, SSH clients will see a host-key change warning. Administrators must distribute the new fingerprints through a trusted channel before users reconnect.

Detection hints

Look for abnormal repeated execution of sensitive helpers:

journalctl --since "24 hours ago" | grep -E "ssh-keysign|chage|pidfd|getfd|ptrace"

Check recent authentication and privilege activity:

sudo journalctl --since "24 hours ago" -u ssh -u sshd

sudo grep -E "ssh-keysign|chage|sudo|su|authentication failure" /var/log/auth.log 2>/dev/null || true

sudo grep -E "ssh-keysign|chage|sudo|su|authentication failure" /var/log/secure 2>/dev/null || true

Note: A clean log does not prove the system was not exploited. Local file-read attacks may leave limited traces.

Rollback

Only roll this back if you intentionally use OpenSSH host-based authentication and you have already patched the kernel.

Remove the hardening file

sudo rm -f /etc/ssh/ssh_config.d/99-disable-ssh-keysign.conf

Restore SUID only if host-based authentication is required

sudo chmod u+s /usr/lib/openssh/ssh-keysign 2>/dev/null || true

sudo chmod u+s /usr/lib/ssh/ssh-keysign 2>/dev/null || true

sudo chmod u+s /usr/libexec/openssh/ssh-keysign 2>/dev/null || true

sudo chmod u+s /usr/libexec/ssh/ssh-keysign 2>/dev/null || true

Do not restore SUID unless host-based authentication is required and the system has already been patched.

Final recommendation

Apply the mitigation immediately on exposed or multi-user Linux systems, rotate SSH host keys if compromise cannot be excluded, and install the vendor kernel update as soon as possible.

This mitigation is designed to reduce the risk while the official kernel fix is being deployed. It should not be considered a permanent replacement for patching.