Enable Host-Based SSH Authentication with ssh-keysign

Host-based authentication trusts the machine rather than the person, and ssh-keysign is the quiet, privileged helper that makes it work. ssh starts it only when a connection needs a host signature; you never run it yourself. This guide enables the helper, checks its protected host keys, and verifies the surrounding SSH configuration without ever invoking the helper directly.

Allow about 15 minutes for a client-only check, 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 opens a new login path, so only do this 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 install used here, the package is openssh-client 1:9.6p1-3ubuntu13.19, OpenSSH reports OpenSSH_9.6p1, and the helper sits at /usr/lib/openssh/ssh-keysign. That path is package-specific, so never hard-code it in a script. A normal installed helper is root-owned with the set-user-ID bit set, shown 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 root-owned and readable only by root; matching public certificate files can also be used where they exist. The helper needs at least one usable host private key, so a directory containing only public keys is not enough.

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 one deliberately:

EnableSSHKeysign yes

This option is deliberately no by default, and the ssh-keysign manual page is specific that it can only be enabled in the global /etc/ssh/ssh_config, never in a user's ~/.ssh/config. Keep a backup of the one line you changed, or lean on your configuration-management history, so undoing it later is a one-line job: 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:

enablesshkeysign yes

Result says no? Look for a later setting, an unexpected Host block, or a configuration file your build never reads. The helper itself has no human-facing interface worth calling.

4. Enable and constrain the server side

The client setting alone grants nothing. The destination's sshd must allow host-based authentication, and its trust rules must name which client hosts and users are acceptable. On the server, check the effective settings before changing anything:

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

The server option HostbasedAuthentication defaults to no. Have a specific, reviewed trust design? Edit the server's sshd_config accordingly and set up its host-trust files or per-user rules. Never copy a broad hosts.equiv entry from an example straight into production: one mistake there can trust more machines or accounts than you meant.

Before reloading the SSH service, validate the syntax:

sudo sshd -t

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

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 result that actually matters here; ssh-keysign normally prints no standalone success message because it is purely an internal helper.

Never 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, so direct invocation just produces confusing errors and proves nothing about server trust. Verbose output never attempts host-based authentication at all? Check the client option and the authentication-method order. Attempts it 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 has no 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 what ssh requested. Check the files, their permissions and any matching certificate pair.
• Server never offers host-based authentication. The server setting is still disabled, or the client is not even trying that method. Inspect effective settings on both sides rather than touching private-key permissions.
• Connection breaks after an edit. Leave the existing session open, restore the previous configuration, run the syntax check, and reload only once it passes. That is what stops a configuration experiment turning into a lockout.