In-depth Analysis and Practical Solutions for Git SSH "Warning: Permanently added to the list of known hosts"

Problem Description and Background Analysis

When using Git for remote repository operations, many developers encounter a frequently appearing warning message: "Warning: Permanently added '...' (RSA) to the list of known hosts". Although this warning does not affect Git's normal functionality, it repeats with every SSH connection, causing unnecessary distraction for developers.

Root Cause Investigation

Through in-depth analysis of the OpenSSH client, we found this issue primarily occurs in Git environments on Windows platforms. When the SSH client attempts to connect to a remote host, it checks known_hosts files in a specific sequence:

debug3: check_host_in_hostfile: filename /dev/null
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts
debug3: check_host_in_hostfile: filename /dev/null
debug3: check_host_in_hostfile: filename /etc/ssh/ssh_known_hosts

From the debug output, we can observe that the SSH client first checks /dev/null, then the system-level /etc/ssh/ssh_known_hosts file, but ignores the user directory's ~/.ssh/known_hosts file. Since it cannot find the known_hosts file in the expected location, the SSH client adds the new host key to the default location and generates the warning message.

Core Solution

To permanently resolve this issue, we need to explicitly specify the location of the known_hosts file in the SSH configuration file. Here are the detailed configuration steps:

First, create or edit the SSH configuration file in the user directory:

# Create ~/.ssh/config file (if it doesn't exist)
touch ~/.ssh/config

Then add the following content to the configuration file:

UserKnownHostsFile ~/.ssh/known_hosts

This configuration directive tells the SSH client to use the known_hosts file in the user directory to store known host information. After configuration, you will still see the warning message during the first connection to a remote host, as the system needs to add the host key to the specified file. However, from the second connection onward, since the host information already exists in the known_hosts file, the warning will no longer appear.

Alternative Approaches Comparison

Besides the core solution mentioned above, there are several other approaches in the community:

Approach 1: Adjust Log Level

By setting LogLevel=quiet or LogLevel=ERROR, you can hide the warning messages:

# Add to ~/.ssh/config
LogLevel=quiet

Or through command-line parameters:

ssh -o LogLevel=quiet git@github.com

The advantage of this method is its simplicity, but the drawback is that it only hides the warning messages without actually solving the known_hosts file location issue.

Approach 2: Disable Host Key Checking

In some cases, developers choose to completely disable host key checking:

Host *
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null
   LogLevel ERROR

While this approach eliminates all related warnings, it introduces serious security risks. Disabling host key checking may make the system vulnerable to man-in-the-middle attacks, therefore it is not recommended for production environments.

Best Practices Recommendations

Based on the evaluation of various approaches, we recommend adopting the core solution as the best practice:

1. Explicitly specify known_hosts file path: Use UserKnownHostsFile ~/.ssh/known_hosts configuration to ensure the SSH client uses the correct file location
2. Maintain default security settings: Do not easily disable StrictHostKeyChecking to maintain SSH connection security
3. Appropriate log levels: In development environments, you can adjust log levels appropriately, but in production environments, it's recommended to keep default settings for troubleshooting purposes

Verification and Debugging

After configuration, you can verify the SSH connection and view detailed debug information using the following command:

ssh -vvv git@github.com

In the debug output, you should be able to see that the SSH client now correctly checks the ~/.ssh/known_hosts file instead of the default system location.

Cross-Platform Compatibility Considerations

Although this issue is more common on Windows platforms, similar configuration methods apply to other operating systems. SSH client behavior may vary slightly across different platforms, but the core configuration principles remain consistent. We recommend developers adopt unified SSH configurations across all development environments to ensure consistent behavior and experience.

By implementing the solutions described in this article, developers can effectively eliminate annoying warnings during Git SSH connections while maintaining system security and stability. This configuration approach not only solves the current problem but also provides a solid foundation for future SSH connection management.