When cleaning up SSH configurations on macOS Monterey 12.1, many developers encounter confusing debug messages suggesting SSH still looks for deleted known_hosts2 files. The verbose output (-v flag) reveals:

debug1: load_hostkeys: fopen /Users/username/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory

SSH maintains a hardcoded list of default locations it checks for host keys, which includes both known_hosts and known_hosts2 variants. This behavior stems from:

• Historical backward compatibility (OpenSSH once used known_hosts2 format)
• System-wide configuration defaults in /etc/ssh/ssh_config
• Potential cached configurations in ssh-agent

To permanently eliminate these warnings:

# 1. Check system-wide configuration
grep -r "known_hosts2" /etc/ssh/

# 2. Verify no custom config overrides exist
cat ~/.ssh/config | grep -i "UserKnownHostsFile"

# 3. Explicitly set host file location (add to ~/.ssh/config)
Host *
    UserKnownHostsFile ~/.ssh/known_hosts
    GlobalKnownHostsFile /etc/ssh/ssh_known_hosts

# 4. Clear any cached keys
ssh-add -D

These messages are debug-level notifications and don't affect functionality. The SSH client simply checks all possible host key locations as part of its standard security verification process. You can:

• Ignore them if they don't cause operational issues
• Increase log level threshold (LogLevel QUIET in ssh_config)
• Filter verbose output: ssh -v user@host 2>&1 | grep -v "known_hosts2"

For developers needing absolute control:

# Download OpenSSH source
git clone https://github.com/openssh/openssh-portable

# Modify hostkey.c (around line 150):
/* Remove or comment out known_hosts2 references */
static const char *default_key_files[] = {
    "known_hosts",
    "ssh_known_hosts",
    NULL
};

# Recompile and install
autoreconf && ./configure --prefix=/usr/local
make && sudo make install

When examining SSH debug output with ssh -v, you might encounter puzzling messages about non-existent known_hosts2 files. This occurs because OpenSSH maintains a standardized search path for host key files, even when some files don't exist on your system.

debug1: load_hostkeys: fopen /Users/user/.ssh/known_hosts2: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts: No such file or directory
debug1: load_hostkeys: fopen /etc/ssh/ssh_known_hosts2: No such file or directory

OpenSSH checks multiple locations for host keys in a specific order:

• ~/.ssh/known_hosts (primary user-specific file)
• ~/.ssh/known_hosts2 (legacy user-specific file)
• /etc/ssh/ssh_known_hosts (system-wide file)
• /etc/ssh/ssh_known_hosts2 (legacy system-wide file)

The debug messages don't indicate these files actually exist - they simply show SSH checking its standard locations. The No such file messages are normal when files aren't present.

The known_hosts2 filename dates back to older OpenSSH versions (pre-5.7) that used different formats:

# Old known_hosts2 format (RSA1 keys)
hostname 1024 37 1234567890abcdef...

Modern OpenSSH maintains backward compatibility by still checking for these legacy files, even though:

1. The format was deprecated in 2011
2. Current versions use known_hosts for all key types

While these messages might look concerning, they're harmless. However, if you want to ensure your SSH configuration is clean:

# Check for any actual known_hosts2 files
find ~/.ssh /etc/ssh -name "*known_hosts2*"

# Verify your known_hosts file format
ssh-keygen -H -f ~/.ssh/known_hosts

The debug messages will persist because they're hardcoded in OpenSSH's source. You can safely ignore them unless you're troubleshooting specific host key verification issues.

Only investigate further if you see:

• Actual errors (not "No such file" messages)
• Host key verification failures
• Unexpected prompts about host keys

In these cases, check your SSH version and configuration:

ssh -V
cat /etc/ssh/ssh_config | grep -i "HostKeyAlgorithms"