Possible attacks over SSH

Question

Let's say there is a target machine T, to which I want to connect. T is in a private network so I need to connect to it via some proxy machine P (which is connected to that network). For this reason I first ssh to P and from there I ssh again to T.

Let's assume P is malicious. How dangerous is can that be for my machine M and what could be possible attack directions? Can P perform some kind of MITM attacks between M and T?

Answer 1

For this reason I first ssh to P and from there I ssh again to T.

If I interpret this correctly you log into P, get a shell and then run ssh from within this shell. If P is compromised you can not trust that you get the expected terminal, not the expected shell and not the expected ssh binary. Everything can be bugged, i.e. all keystrokes (including passwords) you do can be intercepted, all input and output recorded or even modified before sending.

Answer 2

If you use openssh (> 7.3, if I recall) it has a ProxyJump feature that assures there will not be any MITM capability. (Even earlier versions can achieve the same thing, but ProxyJump makes it just so convenient!)

ssh -J me@P me@T

Done.

Here's the snippet from man ssh:

-J destination
    Connect to the target host by first making a ssh connection to the
    jump host described by destination and then establishing a TCP
    forwarding to the ultimate destination from there.

Your client first connects to the jump host, and tells the jump host to establish a 2-way pipe between your client and port 22 of the target. Then your client uses that 2-way pipe to establish an ssh connection with the target. The jump host is doing nothing but ferrying bits -- any "attack" is limited to a denial of service at worst, nothing more.

Before ssh added "proxyjump", you'd do this like this (the -f below is from memory; I can't remember if it was -f or -N):

ssh -f -L 2222:target:22 me@jumphost
ssh -p 2222 [email protected]

But proxyjump makes it much easier.

Answer 3

First, assumptions:

• Assuming it is permitted (and it may well not be) and
• Assuming that you have an accurate public key for T (you'd have to acquire it through a channel that doesn't pass through P) stored on S.

If these assumptions hold, you can establish a port forward between S (your source system) and P that permits you to connect directly from S to T (thanks for the comment @sitaram). Then you should be able to SSH directly from S to T, verifying T with its public key, and have no vulnerability to P being compromised (you either have no connection, or a secure one).

Commands:

S:> ssh -L 9999:T:22 Puser@P  # Don't use this shell, but keep it running.
S:> ssh -p 9999 [email protected]  # Use this shell

This should mitigate the attack you outlined where P is untrustworthy. It does, however, expose the SSH port for T to any user on machine S, so you should make that choice with awareness/caution.

Answer 4

While looking at related questions I've spotted two important concepts:

1. SSH Agent Forwarding (see answer here). In the case mentioned in the question, the root on malicious machine P can use M's private ssh key to authenticate with other servers.

2. X11 Forwarding (when ssh'ing using flag -X, i.e. ssh -X user@host ), where the server could execute commands back on the client machine.