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?


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.

| improve this answer | |
  • Thank you for your quick answer. I was also considering the kind of attacks that P can perform on my machine but I guess this is a completely different topic and (I recon) equivalent to asking "What are the dangers of ssh'ing into malicious machine?" or even "How secure is SSH". – Tomasz Dec 15 '19 at 11:28
  • 2
    @TomaszBartkowiak: Yes, it is a different topic and it is also covered here in multiple questions, like What are the risks of SSHing to an untrusted host?. – Steffen Ullrich Dec 15 '19 at 11:39

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


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 me@

But proxyjump makes it much easier.

| improve this answer | |

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


S:> ssh -L 9999:T:22 Puser@P  # Don't use this shell, but keep it running.
S:> ssh -p 9999 Tuser@  # 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.

| improve this answer | |
  • 1
    Ouch! The untrusted host has a key that can log in to the target? That's "game over" in my book. – sitaram Dec 19 '19 at 14:37
  • Oh, nice point. I guess it should be just the first and last SSHes, and the port forward from the first going all the way to T. Good catch. It has been quite a long time since I've played with SSH, sadly. – Slartibartfast Dec 24 '19 at 7:11

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.

| improve this answer | |

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.