I am presented with SSH log from a SSH server and the said SSH server only accepts connection from 2 known public IPs over WAN.

The content of the log shows that a user was successfully authenticated. However, that user authenticated from an unknown public IP. Here is an excerpt of the log.

Nov 23 06:32:46 SSHSrv-SFTP sshd[13717]: Accepted password for ftpuser from aaa.bbb.ccc.ddd port 5649 ssh2
Nov 23 06:32:46 SSHSrv-SFTP sshd[13717]: pam_unix(sshd:session): session opened for user ftpuser by (uid=0)
Nov 23 06:34:34 SSHSrv-SFTP sshd[13717]: pam_unix(sshd:session): session closed for user ftpuser

I have read around and found that this could be a MitM attack. However, wouldn't an attacker utilize a spoofed IP instead of its own IP?

3 Answers 3


The evidence you've got doesn't point to a MITM attack I'd say. With a MITM attack the traffic would typically appear to come from the correct IP address, rather than another one. Another point worth noting is that MITM'ing an SSH connection would likely cause warnings on the client as the fingerprint of the server would be different.

This looks more like a failure in Access Control. If the access control is intended to be implemented by the SSH daemon (i.e. it is set to only log people in from specific IP addresses) then it's failing to do so by accepting a connection from another address.

If the restriction is implemented elsewhere (e.g a firewall device) then it looks like a possible misconfiguration in that service.


The basics of any TCP MITM attack don't vary by application-level protocol.

Intercepting a TCP stream can be done by any one of a number of tactics, including but not limited to: Malicious networks (including malicious WiFi networks), Spoofed DHCP responses, ARP spoofing, and DNS redirection, just to name a few.

This applies to SSH just as much as it applies to HTTP or SMTP. The protocol-specific protection (in this case the checking of host keys) is your primary defense, no matter how the MITM insertion happens.


"Man-in-the-Middle attack" is a concept which can be realized in several ways. The idea is that the attacker contrived to make the traffic between an honest client and the genuine server go through his own systems, and also managed to bypass the cryptographic protections (more on this later on).

One possible situation is that the attacker is fortunate enough to have control over a router which is normally involved in the routing of the traffic between client and server. In that case, no IP address is spoofed or changed; the attacker just blocks and inserts packets on the flow.

A less fortunate attacker would have to redirect things. For instance, through DNS poisoning, the attacker could make the client use his IP address instead of the normal IP address. But fooling the client is only half of the MitM; the attacker must also talk to the actual server (otherwise, that's not MitM but merely server impersonation). When talking to the server, the attacker must be able to send packets to the server, but also see the packets from the server. In our example, the attacker cannot see such answers if they are sent by the server to the honest client's IP; thus, the attacker must use his own IP address (at least, one address that he controls) in his dealings with the server, and that IP address will show up in the server's log.

In other words, whether the IP address as seen from the server will be that of the normal client, or another one, is not implied by the existence of a MitM attack. Depending on the circumstances, the attacker may need to show a distinct IP address to the server, or not. Conversely, there are many network situations where an IP address is "changed" although there is no attack at all; e.g. the client is behind a NAT. Nowadays, a very common reason for unexpected IP addresses is mobility: the client uses a laptop, tablet or smartphone, configured to automatically connect to the nearest open-access WiFi; the user just walked in range of another access point, implying a new IP address.

In any case, a MitM attack is double impersonation: the attacker poses as the client when talking to the server, and as the server when talking to the client. From the server side, you see only one half of the suspected MitM. You merely suppose that the true client was involved, on the basis that the server accepted the password which is assumed to be known to the true client only. However, this raises another question, which is: how did the attacker fool the client ?

Indeed, SSH uses a lot of cryptography, and, in particular, clients are supposed to remember the server's public key. Upon first connection ever to a given server, the client should display the hash of the server's public key to the human user (for confirmation), and, afterwards, the client will noisily reject the connection attempt if the server appears to have changed his key (from the client point of view). As long as the client knows the correct server public key, server impersonation attacks, and a fortiori MitM attacks, are prevented by the asymmetric cryptography which takes place at the beginning of the SSH connection.

In order to achieve a MitM on some SSH connection, the client must be coaxed into accepting a fake server's public key, despite the visible warnings from the client software. This is not easy when the server is already known to the client software from a previous connection.

From all of this, I conclude the following:

  • The most probable case is that the connection is from the correct user, but a networking configuration quirk changed the apparent IP address because of some NAT or VPN or mobile user or whatever at some point. This may even occur close to the server, e.g. between the SSH server itself and its firewall.

  • If there is an attack, then the most plausible is that the password has somehow leaked (e.g. with a malware-installed keylogger on the client). A real MitM setup needs not be invoked, because it implies some extra hypotheses on the client side (bypass of server key fingerprint). In any case, if there is a successful MitM, then the attacker sees the password, and can thereafter connect back by himself, without doing any further MitM.

  • If you have on the server side a restriction on allowed client IP addresses, and the server accepts a connection from an IP address which is not allowed, then all we can say is that this restriction... does not work. So, in any case, you should make some extra tests to ascertain whether what you believe to be the network configuration of your firewalls really matches reality.

A wild guess may be the following: in your setup, the SSH server may have an "internal" IP address, and be connected to the Internet through a router which has both another internal IP address and a public IP address, the latter being what the clients see and use. The router was furthermore configured to forward connections on its port 22 to the SSH server; but the server may perform this forwarding by opening a TCP connection of its own and relaying data, instead of doing some NAT. In that case, the SSH server will naturally see the connection as coming from the router's internal IP address, not the actual client's address.

  • The OP said that the log-in was from an "unknown public IP address" (emphasis mine). AFAICT, if that was true, then your wild guess seems unlikely to be correct. Jan 26, 2018 at 21:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.