Two weeks ago, I challenged you to figure out how a machine was compromised. Let me quickly recap the situation. I suspected that someone was using an SSH man-in-the-middle package on the local network. Both sshmitm (part of Dug Song's dsniff[1] . . .
Two weeks ago, I challenged you to figure out how a machine was compromised. Let me quickly recap the situation. I suspected that someone was using an SSH man-in-the-middle package on the local network. Both sshmitm (part of Dug Song's dsniff[1] package) and ettercap[2] can fill this role. (As it turns out, the culprit was a modified version of sshmitm, so I'll just call it by name henceforward.)

The machine running sshmitm needs to be situated between the ssh client and ssh server. When the client machine connects to the server, the machine running sshmitm intercepts the packets. The sshmitm process pretends to be the actual server. It will follow the SSH protocol specification, providing the host key, agreeing on cryptographic algorithms and keys, and eventually asking the client for the password.

The sshmitm program establishes a connection to the actual server, as if it's a normal ssh client. It takes the data that it receives from the real client, which it has available in cleartext, and re-encrypts it to the real ssh server as appropriate.

The link for this article located at IT World is no longer available.