Can a SSH jump host act as MITM?

Question

Let's say, for example, a company has a "centralised" SSH bastion/jump host on an untrusted server (e.g. a virtual machine in "the cloud").

Meanwhile the corporate/customer/whatever network(s) have firewall ACLs permitting SSH traffic from the bastion/jump host to the internal SSH server(s).

Is it possible for an evil actor to exploit the jump host to enable viewing of SSH traffic ? Or is the traffic that flows over the jump host always end-to-end encrypted ? (i.e. the bastion/jump host always just sees an encrypted flow because the traffic between client and internal server uses the internal server's keypair).

For the avoidance of doubt over terminology, when I talk about jump host I'm talking about commands such as :

ssh -J bastion.example.com internal.example.com

or

scp -oProxyJump=bastion.example.com internal.example.com

Answer 1

From man ssh

     -J [user@]host[:port]
         Connect to the target host by first making a ssh connection to
         the jump host and then establishing a TCP forwarding to the ulti-
         mate destination from there.  Multiple jump hops may be specified
         separated by comma characters.  This is a shortcut to specify a
         ProxyJump configuration directive.

As it is creating a TCP tunnel from your computer, through the jump host, to the target, two ssh connections will be established, one to the jumphost, and another one inside the tunnel. The one inside the tunnel will be encrypted.

The jumphost could hijack the connection target, but then the key will not match.

Answer 2

When ProxyJump is used, the jump host can not read data from the forwarded ssh session, because this session should be end to end encrypted.

The problem is, when you are using a malicious server as a jump host, the jump host can redirect your second ssh session to another mitm server. If you are using password authentication, a full mitm can be established.

Even public key authentication is not a protection against mitm attacks. Public key authentication makes it more difficult, but not impossible. When agent forwarding is used, a full man in the middle attack is possible.

Comparing server fingerprints is the only thing, which helps against those attacks.

At the moment (march 2021) there are no mitm tools available to intercept connections with proxy jump. Even "ssh-mitm" is not able to intercept those connections, because the port forwarding implementations has some limitations (which can be fixed).

So there are some suggestions:

• always compare the server fingerprint with a known value
• never forward the ssh agent to a remote host
• do not use password authentication

If the jump host is malicious, the connection should be secure as long as the remote host is secure and host keys are verified

Disclosure: I'm the author of ssh-mitm