Enable Host-Based SSH Authentication with ssh-keysign

By the end of this guide, an OpenSSH client will be able to use its machine host key when attempting host-based authentication. The ssh-keysign program is only the privileged signing helper: ssh starts it when the connection needs a host signature. You will enable the helper, check its protected host keys, and verify the surrounding SSH configuration without running the helper as an interactive command.

Allow about 15 minutes for a client-only check and longer if you also administer the server. You need the openssh-client package on the client, root access to edit /etc/ssh/ssh_config and inspect host keys, and administrative access to the destination SSH server. Host-based authentication is security-sensitive: enabling it can create a new login path, so do this only for hosts and accounts you already trust.

1. Confirm the local OpenSSH installation

Run these ordinary inspection commands on the client:

dpkg-query -W -f='${Package} ${Version}\n' openssh-client
ssh -V 2>&1
command -v ssh-keysign || true
ls -l /usr/lib/openssh/ssh-keysign /usr/bin/ssh-keysign 2>/dev/null || true

On the reference Ubuntu installation used for this guide, the package is openssh-client 1:9.6p1-3ubuntu13.19, OpenSSH reports OpenSSH_9.6p1, and the helper is installed at /usr/lib/openssh/ssh-keysign. The path is package-specific, so do not hard-code it in a script. A normal installed helper is owned by root and has the set-user-ID bit, displayed as an s in permissions such as -rwsr-xr-x.

2. Check the host private keys

ssh-keysign reads the client machine's host private keys, not your personal key in ~/.ssh. Inspect the supported key files with elevated privileges:

sudo find /etc/ssh -maxdepth 1 -type f \
  \( -name 'ssh_host_*_key' -o -name 'ssh_host_*_key-cert.pub' \) \
  -exec stat -c '%A %U:%G %n' {} \;

Private files such as /etc/ssh/ssh_host_ed25519_key, ssh_host_ecdsa_key and ssh_host_rsa_key should be owned by root and readable only by root. Public certificate files with matching names may also be used when they exist. The helper needs access to at least one usable host private key; a directory containing only public keys is not enough.

Do not loosen these permissions to make a failed login work. That would expose a machine identity which can be used to sign host-based authentication requests. If the files are missing, use your distribution's supported OpenSSH host-key generation or package-repair procedure, then check the permissions again.

3. Enable the client helper

Edit the global client configuration as root:

sudoedit /etc/ssh/ssh_config

Add this setting outside any accidental per-host block, or change an existing setting deliberately:

EnableSSHKeysign yes

This option is deliberately no by default. The ssh-keysign manual page specifies that it can be enabled only in the global /etc/ssh/ssh_config, not in a user's ~/.ssh/config. Keep a backup of the one line you changed, or use your normal configuration-management history, so undoing the change is simple: remove it or restore EnableSSHKeysign no.

Check the effective client configuration without connecting:

ssh -G server.example 2>/dev/null | grep -i '^enablesshkeysign '

Expected output is:

enablesshkeysign yes

If the result is no, check for a later setting, an unexpected Host block, or a configuration file that your build does not read. The helper itself does not provide a useful human-facing command interface.

4. Enable and constrain the server side

The client setting alone does not grant access. The destination's sshd must allow host-based authentication, and its trust rules must identify which client hosts and users are acceptable. On the server, inspect the effective settings before changing anything:

sudo sshd -T | grep -Ei '^(hostbasedauthentication|ignoreuserknownhosts|ignorerhosts) '

The server option HostbasedAuthentication defaults to no. If you have a specific, reviewed trust design, edit the server's sshd_config accordingly and configure its host-trust files or per-user rules. Do not copy a broad hosts.equiv entry from an example into production: a mistake there can trust more machines or accounts than intended.

Before reloading the SSH service, validate the syntax:

sudo sshd -t

No output and exit status 0 means the file parsed successfully. If it fails, fix the reported line before reloading. Keep an existing session open while applying a server change, and use your platform's documented service-manager command to reload sshd. If the change causes trouble, revert the edited lines, run sudo sshd -t again, and reload once the configuration is valid.

5. Test the complete authentication path

Use a verbose connection to the intended server and account:

ssh -vvv -o HostbasedAuthentication=yes [email protected]

Read the diagnostic stream for host-based authentication and, if it is offered, a successful signature request. A successful login is the useful result; ssh-keysign normally does not print a standalone success message because it is an internal helper.

Do not test by invoking ssh-keysign directly. It expects a private message protocol from ssh, reads request data from standard input, and writes a signature response. Direct invocation can produce confusing errors and does not prove that the server trusts the client. If the verbose client output never attempts host-based authentication, check both the client option and the authentication-method order. If it attempts the method but the server rejects it, inspect the server's effective settings, host-key trust data, account rules and authentication logs.

Common failure boundaries

• "ssh-keysign not enabled": the global client file does not contain an effective EnableSSHKeysign yes. A user configuration entry is not a substitute.
• "could not open any host key" or "no hostkey found": the helper cannot read a usable root-owned host private key, or none matches the key requested by ssh. Check the files, their permissions and any matching certificate pair.
• The server never offers host-based authentication: the server setting is still disabled, or the client is not trying that method. Inspect effective settings on both sides rather than changing private-key permissions.
• The connection breaks after an edit: leave the existing session open, restore the previous configuration, run the syntax check, and reload only after it passes. This avoids turning a configuration experiment into a lockout.