Host-Based Authentication for Trusted Servers

Host-based authentication allows one server to authenticate to another based on the client machine’s host key, rather than user keys. This is particularly useful in enterprise environments where you have trusted servers that need automated, passwordless communication.

When to Use Host-Based Authentication

I use host-based authentication in these scenarios:

• Automated backup systems pulling data from multiple servers
• Configuration management systems (Ansible, Puppet)
• Monitoring systems that need to execute remote commands
• Database replication between trusted servers
• CI/CD pipelines deploying to production

Architecture Overview

Host-based authentication works like this:

1. Client machine has a host key pair in /etc/ssh/
2. Server trusts specific client hostnames
3. During connection, client proves its identity using the host key
4. Server verifies the hostname and host key match

Prerequisites

• Root access on both client and server
• Proper DNS or /etc/hosts entries for hostname resolution
• Network trust between machines

Step 1: Enable Host-Based Authentication on Server

Edit /etc/ssh/sshd_config on the server (the machine being connected to):

sudo nano /etc/ssh/sshd_config

Add or modify these settings:

# Enable host-based authentication
HostbasedAuthentication yes

# Trust user@host combinations (more secure)
HostbasedUsesNameFromPacketOnly yes

# Require both user key and host-based auth (optional, very secure)
# AuthenticationMethods publickey,hostbased

# Accept these key types for host authentication
HostbasedAcceptedKeyTypes ssh-ed25519,rsa-sha2-512,rsa-sha2-256

# Don't ignore rhosts (needed for host-based auth)
IgnoreRhosts no

# Still require proper user mapping
IgnoreUserKnownHosts no

Restart SSH:

sudo systemctl restart sshd

Step 2: Configure Trusted Hosts on Server

Create or edit /etc/ssh/shosts.equiv on the server:

sudo nano /etc/ssh/shosts.equiv

Add trusted hostnames (one per line):

# Format: hostname [username]
backup-server.example.com deployer
monitoring.example.com monitor
ci-runner-01.example.com jenkins

Set proper permissions:

sudo chmod 600 /etc/ssh/shosts.equiv
sudo chown root:root /etc/ssh/shosts.equiv

Alternative per-user configuration:

# User-specific trusted hosts
nano ~/.shosts

# Add trusted hosts
backup-server.example.com
monitoring.example.com

Step 3: Configure Client Machine

On the client machine (the one initiating connections), edit /etc/ssh/ssh_config or ~/.ssh/config:

sudo nano /etc/ssh/ssh_config

Add these settings:

# Enable host-based authentication
HostbasedAuthentication yes

# Send local hostname
EnableSSHKeysign yes

# Prefer host-based auth
PreferredAuthentications hostbased,publickey,password

Step 4: Configure SSH Keysign

The ssh-keysign program must be setuid root to access host keys:

# Verify ssh-keysign location
which ssh-keysign
# Usually: /usr/lib/openssh/ssh-keysign or /usr/libexec/openssh/ssh-keysign

# Set proper permissions
sudo chmod 4711 /usr/lib/openssh/ssh-keysign
# or
sudo chmod 4711 /usr/libexec/openssh/ssh-keysign

Step 5: Distribute Host Public Keys

On the client machine, find the host public key:

# Usually ssh_host_ed25519_key.pub or ssh_host_rsa_key.pub
sudo cat /etc/ssh/ssh_host_ed25519_key.pub

Copy this key to the server’s known hosts file:

# On the server
sudo nano /etc/ssh/ssh_known_hosts

Add an entry in this format:

# Format: hostname,ip key-type public-key
backup-server.example.com,192.168.1.10 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAILo...
monitoring.example.com,192.168.1.20 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIXy...

Set proper permissions:

sudo chmod 644 /etc/ssh/ssh_known_hosts
sudo chown root:root /etc/ssh/ssh_known_hosts

Step 6: Test Host-Based Authentication

From the client machine, test the connection:

# Test with verbose output
ssh -v [email protected]

# Look for this in the output:
# "Offering public key: /etc/ssh/ssh_host_ed25519_key"
# "Server accepts key: /etc/ssh/ssh_host_ed25519_key"
# "Authentication succeeded (hostbased)"

Automation Script for Multiple Clients

I use this script to distribute host keys from multiple clients to a central server:

Save as /usr/local/bin/distribute-host-keys.sh on the server:

#!/bin/bash
# Collect and distribute host keys for host-based authentication

KNOWN_HOSTS="/etc/ssh/ssh_known_hosts"
TEMP_KEYS="/tmp/host_keys_collection.txt"

# List of client machines
CLIENTS=(
    "backup-server.example.com"
    "monitoring.example.com"
    "ci-runner-01.example.com"
)

echo "Collecting host keys from client machines..."
> $TEMP_KEYS

for client in "${CLIENTS[@]}"; do
    echo "Fetching key from $client..."

    # Get hostname and IP
    IP=$(dig +short $client | tail -1)

    # Fetch the host key
    KEY=$(ssh-keyscan -t ed25519 $client 2>/dev/null)

    if [ -n "$KEY" ]; then
        # Format: hostname,ip key-type key
        echo "$client,$IP $(echo $KEY | awk '{print $2, $3}')" >> $TEMP_KEYS
        echo "  ✓ Key collected from $client"
    else
        echo "  ✗ Failed to get key from $client"
    fi
done

# Backup existing known_hosts
if [ -f $KNOWN_HOSTS ]; then
    cp $KNOWN_HOSTS ${KNOWN_HOSTS}.backup.$(date +%F)
fi

# Add new keys
cat $TEMP_KEYS >> $KNOWN_HOSTS

# Remove duplicates and sort
sort -u $KNOWN_HOSTS -o $KNOWN_HOSTS

# Set permissions
chmod 644 $KNOWN_HOSTS

echo "Host keys distributed successfully!"
echo "Backup saved to ${KNOWN_HOSTS}.backup.$(date +%F)"

Make it executable:

sudo chmod +x /usr/local/bin/distribute-host-keys.sh
sudo /usr/local/bin/distribute-host-keys.sh

Security Considerations

Pros:

• No credential management for automated processes
• Host identity verification
• Useful for trusted server-to-server communication

Cons:

• If client machine is compromised, attacker gains access
• Harder to audit than user-based authentication
• Requires careful hostname management

Best Practices I Follow:

1. Use with User Keys: Combine with publickey authentication:

   AuthenticationMethods publickey,hostbased

2. Limit to Specific Commands: Use command= in authorized_keys for restriction

3. Network Segmentation: Only allow host-based auth from trusted network segments

4. Regular Audits: Review /etc/ssh/shosts.equiv monthly

5. Logging: Ensure verbose logging to track host-based authentications:

   LogLevel VERBOSE

6. Firewall Rules: Restrict SSH access to only trusted client IPs

Monitoring Host-Based Authentications

Add to your monitoring script:

# Check for host-based authentication attempts
echo "Host-Based Authentications:" >> $REPORT_FILE
grep "hostbased" /var/log/auth.log | tail -20 >> $REPORT_FILE
echo "" >> $REPORT_FILE

Troubleshooting

Connection fails with “Permission denied”:

1. Check server logs:

   sudo journalctl -u sshd -n 50 | grep hostbased

2. Verify hostname resolution:

   # On server
   hostname -f
   # Should match what's in shosts.equiv

3. Check ssh-keysign permissions:

   ls -l /usr/lib/openssh/ssh-keysign
   # Should be: -rws--x--x (4711)

4. Verify host key on server:

   sudo grep "$(hostname)" /etc/ssh/ssh_known_hosts

Debug mode:

# On client, test with maximum verbosity
ssh -vvv -o PreferredAuthentications=hostbased user@server

Revoking Host Access

To revoke a client’s access:

1. Remove from /etc/ssh/shosts.equiv:

   sudo nano /etc/ssh/shosts.equiv
   # Delete the line with the hostname

2. Remove from /etc/ssh/ssh_known_hosts:

   sudo ssh-keygen -R hostname.example.com -f /etc/ssh/ssh_known_hosts

3. Restart SSH:

   sudo systemctl restart sshd

Real-World Example: Backup Server Setup

Here’s how I configure a backup server to pull data from multiple production servers:

On production servers (/etc/ssh/sshd_config):

HostbasedAuthentication yes
Match User backup
    HostbasedAuthentication yes
    PasswordAuthentication no
    AllowUsers backup

On production servers (/etc/ssh/shosts.equiv):

backup-server.example.com backup

On backup server (/etc/ssh/ssh_config):

Host prod-*
    HostbasedAuthentication yes
    PreferredAuthentications hostbased
    User backup

Now the backup server can automatically connect:

rsync -avz prod-web-01:/var/www/ /backup/web-01/

Next Steps

Proceed to the Security Monitoring guide to implement fail2ban, connection management, and comprehensive log analysis for your hardened SSH setup.