Introduction
When connecting to a Linux server via SSH, you may encounter a situation where the host key fingerprint differs from what is recorded in your known_hosts file. This scenario can trigger alarm bells, indicating a possible security risk. Understanding the technical aspects behind these changes is crucial for effective server management and maintaining security.
Attempting to Connect
During your connection attempt to a server, you might use the following command:
ssh -i ~/.ssh/id_rsa_gitlab [email protected]
Warning Message
You may receive a message such as:
The authenticity of host '192.0.2.1 (192.02.1)' can't be established.
ED25519 key fingerprint is SHA256:ABC123...
Are you sure you want to continue connecting (yes/no)?
This message indicates that the SSH client cannot verify the authenticity of the host because the fingerprint does not match the one stored in your known_hosts file. This discrepancy can arise from legitimate changes on the server (e.g., key rotation, reinstallation) or malicious activities (e.g., man-in-the-middle attacks).
Investigation Steps
1. Check Your known_hosts File
First, examine your known_hosts file for the entry corresponding to the server IP. Open the file using:
nano ~/.ssh/known_hosts
You might find an entry like:
192.0.2.1 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...
2. Verify Server Keys
To confirm the current key on the server, access it directly (via console access or other means) and run:
ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
You’ll likely receive an output similar to:
256 SHA256:XYZ456... root@server (ED25519)
3. Compare Fingerprints
It’s crucial to compare the fingerprint obtained from the server with the one stored in your known_hosts. If they do not match, this discrepancy indicates a potential security issue. It could mean that the server’s host key has changed, or worse, that a man-in-the-middle attack is in progress.
What Actions to Take?
4. Check Users on the Server
Before making any changes, verify the users on the server to ensure everything is in order. Use the command:
cat /etc/passwd
Example Output:
root:x:0:0:root:/root:/bin/bash
user1:x:1001:1001:User One,,,:/home/user1:/bin/bash
user2:x:1002:1002:User Two,,,:/home/user2:/bin/bas
user3:x:1003:1003:User Three,,,:/home/user3:/bin/bash
user4:x:1004:1004:User Four,,,:/home/user4:/bin/bash
5. Check for Sudo Rights
Check which users have sudo rights:
sudo -l
6. Identify Key Changes
To find out why the key has changed, examine the authentication logs:
sudo cat /var/log/auth.log
Look for suspicious login attempts or recent changes:
Oct 29 07:40:21 server sshd[123317]: Invalid user unknown from 8.219.230.110 port 40402
Oct 29 07:40:51 server sshd[123334]: Accepted publickey for user1 from 192.0.2.1 port 46855 ssh2: ED25519 SHA256:ABC123...
Decision Point
If you confirm that the change is legitimate, you may consider updating your known_hosts file. This step is crucial to prevent potential man-in-the-middle attacks.
1. Remove the Old Entry:
Use the command:
ssh-keygen -R 192.0.2.1
2. Add the New Key:
You can manually edit your known_hosts:
nano ~/.ssh/known_hosts
Add the new key:
192.0.2.1 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIP7t4H1BzVSUWT3zlONVx4iOzY64IDt4sSXxfWQ9u2uS
Conclusion
Encountering a situation where the host key changes requires caution. Verify keys and ensure secure connections to protect against potential attacks. If you’ve checked the users, their rights, and the logs, and if the key change is legitimate, replacing the entry in your known_hosts with the correct server key will help maintain security and ensure proper functionality in your SSH connections.
By following these steps, you can mitigate risks and maintain a secure server environment.
