"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.