Introduction

Why hostnames and IP addresses cannot be trusted for SSH authentication

Common Attack Vectors

DNS poisoning

Hosts file poisoning

Network-level and routing attacks

Host Key Verification: How SSH Verifies the Server's Identity

When the Fingerprints Don't Match

But What Is a Fingerprint in the First Place?

Common Questions and Misconceptions

If I see a host key verification error, am I under a man-in-the-middle attack?

Why would anyone intentionally disable host key verification?

What if I’m connecting via VPN or a private network?

What about automation tools like Ansible?

Do testing environments really need this level of caution?

Conclusion

Bibliography SSH (Secure Shell) is a cornerstone of modern computing. It’s no exaggeration to say that almost every software engineer and IT administrator has used an SSH client to manage a remote machine at some point of their careers. This protocol has been around since 1995 and it remains the gold standard of secure shell access. SSH provides encrypted tunnels over insecure networks, allowing secure access to remote machines. While the protocol itself is very robust and mature, its security ultimately depends on how it is used. Misconfigurations, inexperience and lack of knowledge can be an open door for attackers. And I’m speaking from experience. I've used SSH in insecure ways in the past, mainly because I didn’t fully understand how to protect my systems and applications correctly. In this series of three parts, we will explore how SSH can be misused, how attackers exploit common pitfalls, and how to avoid them. In the first part, we’ll discuss why you shouldn’t blindly trust the server you’re connecting to, and provide a high-level overview of how host key verification works. In the second part, we'll go through a small lab exercise to demonstrate a Man-in-the-Middle (MITM) attack, showing how an attacker can capture credentials and monitor live user activity. The last part focuses on hardening and best practices. We’ll cover practical, actionable security measures to protect your infrastructure and applications. When you SSH to a remote machine, are you sure you are connecting to the right server? You might think that double-checking the hostname or IP address eliminates the risk, but that's not true. Verifying a destination address is not enough to guarantee a server's identity. At first glance, trusting an SSH connection based on a hostname seems secure. If you point your client toward server.example.com, it feels like you must be connecting to the right place, right? However, hostnames and IP addresses are not inherently trustworthy, especially outside private networks; they depend on multiple layers of infrastructure that can be manipulated. For this reason, SSH security relies on cryptographic host key verification rather than simply trusting where the network appears to be routing your traffic. There are different methods that can be used to redirect a connection to a malicious server without you even noticing, including: We will cover these attacks in the following sections. When you connect using a hostname (e.g., ssh server.example.com), your system relies on DNS to resolve it to an IP address. Because low-level network communication requires IP addresses rather than human-readable names, this resolution step is a critical point of failure. In a DNS poisoning attack, an actor corrupts this resolution process so that a legitimate hostname resolves to a malicious IP address. This silently redirects your SSH connection, making the redirection nearly impossible to detect if you rely solely on the hostname for trust. Operating systems can override external DNS resolution using a local hosts file (e.g., /etc/hosts on Linux). If an attacker gains sufficient access to your machine, they can modify this file to force trusted hostnames to point to malicious IP addresses. While an attacker with this level of access could likely cause even more damage to your machine, this technique remains effective because it is simple and redirects traffic without raising immediate suspicion. It is important to note that hosts file poisoning is not a network attack, but rather a post-compromise persistence or redirection technique that bypasses DNS entirely. Even if your DNS and local configurations are secure, the network path itself may be compromised. Attackers who control or compromise routers and switches can intercept or alter traffic in transit. This enables man-in-the-middle attacks, particularly on untrusted networks like public Wi-Fi or poorly secured internal LANs. At a larger scale, global internet routing can be manipulated as well. Attacks such as Border Gateway Protocol (BGP) hijacking allow malicious actors to redirect traffic through attacker-controlled networks, even when the destination IP address seems correct. Furthermore, IP addresses themselves are not permanent guarantors of a server's identity. In cloud environments, for example, IPs are frequently reassigned, meaning an address you trusted yesterday may belong to a completely different system today. When you connect to a remote machine for the first time using SSH, your client likely does not know the server's public key yet. That is because the client has no record of this server, it will present a cryptographic fingerprint and ask if you want to proceed: When you type yes, the server's public key is saved to the ~/.ssh/known_hosts file in your home directory. You can inspect this file to see the stored key: The next time you connect, the SSH client will compare the key provided by the server against the one stored in your known_hosts file. If they match, the connection proceeds. However, if the host key does not match, the OpenSSH client blocks the connection and displays an alarming warning: This is the default behavior of the OpenSSH client, and it is your primary line of defense. It forces you to stop and investigate what happened, before continue and potentially send data or credentials to a malicious server. An SSH key fingerprint is a condensed, hash-based and fixed-length representation of a much larger public key. You might wonder: Why do we need a fingerprint if we can just check the public key directly? Essentially, for human readability and consistency. Public keys can be incredibly long and vary in size depending on the algorithm used (RSA vs ED25519). Displaying a short, fixed-length fingerprint is much more convenient for manual verification, logging, and monitoring. For example, consider this known_hosts file generated by pulling the public keys for GitHub: As you can see, the keys have different lengths, especially the RSA key, which is quite huge. Trying to visually compare those strings would be a nightmare. However, if we compute the fingerprints using ssh-keygen, the data becomes much more manageable: Much easier to read, isn't it? Not necessarily, but you should never ignore the error. A server's public key can change for legitimate reasons, such as: You must verify that this change is valid before proceeding. It often happens because skipping the check feels "simpler" during development, especially when learning to use SSH libraries. These libraries often include warning logs specifically to alert developers who forget to implement verification. While disabling it might save time during a "Hello World" project, it creates a massive security hole if that code ever reaches production. You might argue that internal infrastructure is "safe," but that is exactly the assumption attackers rely on. However, once an attacker is inside your VPN, they can compromise one or more machines. The risk is lower than the open internet, but it is never zero. This is one of the most common places where verification is disabled. Developers are often tempted to bypass host key verification to avoid friction when configuring and managing environments. This is typically done in one of three ways: While this simplifies the first stages of a project, it is a habit that must be broken. Eventually, you should implement a proper verification strategy (like using a Certificate Authority or pre-populating known_hosts), especially when connecting to machines outside your immediate control. You might think a test server has no useful data, but that depends on your configuration. Attackers often use "low-value" environments as a stepping stone. If your test environment uses the same credentials or has network access to your production database, a stolen SSH session on a testing machine could potentially compromise the rest of the company's infrastructure. The risk is naturally lower when working with ephemeral and immutable infrastructure, where machines are frequently destroyed and recreated. In contrast, environments with long-lived infrastructure should always apply strict SSH host key verification practices. In this first part, we discussed how SSH verifies a server's identity and why hostnames and IP addresses are not reliable guarantors of that identity. We explored how attackers can manipulate network infrastructure via DNS poisoning, host file modification, or routing attacks to take advantage of poor SSH configurations. Knowing the risks of improper SSH configurations is the first step toward hardening applications and infrastructure that rely on SSH. In the next article, we will move from theory to practice. We’ll walk through a lab exercise to demonstrate exactly how an attacker can steal credentials and monitor live user activity using a man-in-the-middle attack. Stay tuned for Part 2! Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to ? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse