13

I'm evaluating what is the better technique for SSHing into my machines securely, without trusting third parties.

I can connect to my machines through an SSH tunnel, but I need a server in between.

As far as I understood, the target local machine connects to the server through SSH tunneling, that is, it forwards everything from server:port to local:22. This is in the TCP level, so it's equivalent as having an open SSH port in the wild, which is not a problem.

However, can the server do something malicious through this reverse connection? Besides something that anyone with TCP connection could do, is there something tricky that the server can do?

I mean, something publicly known that can be done. Of course there could be exploits on the openssh server/client

Improve this question
4
  • 1
    I know this isn't your question, but why don't you want to trust third parties? They're called third parties for a reason...
    – Hman66
    Commented Aug 3 at 23:45
  • 2
    I've replaced the term "reverse shell", because it's often associated with an attack technique. The more neutral term would be "SSH tunneling".
    – Ja1024
    Commented Aug 4 at 5:18
  • There is one malicious thing they can do, they can end your connection, or degrade it. Two. That's two malicious things
    – Nacht
    Commented Aug 5 at 1:21
  • Could you clarify with a small diagram of some sort: the 3 devices involved, and what devices connect to what other devices, and where the tunnels are? It seems to me that want you want is to be able to ssh into a server which is on a LAN behind a NAT, so you want to have that server ssh into a server on the public internet with a remote port forwarding? That is nearly equivalent to having port forwarding set up on your router/NAT device, really.
    – jcaron
    Commented Aug 6 at 12:27

2 Answers 2

Reset to default
18

This is tunneling a SSH connection inside another SSH connection and thus is similar to the SSH jump host feature - see also Can a SSH jump host act as MITM?.

While the confidentiality and integrity of the data seems to be protected due to the additional encryption, an untrusted jump host might change the destination of the tunnel - you cannot trust that the endpoint you connect at the jump host is really the tunnel endpoint you expect.

Of course, if the tunnel endpoint is properly checked by connecting only to a tunnel providing the expected host key of your target system, then this is not a problem.

Improve this answer
6
  • So if my target runs ˋssh -R 2222:127.0.0.1:22 user@<remote_server_ip>ˋ on a remove_server_ip, then if I connect over ssh and check public key fingerprints, then I'm ok?
    – aaa
    Commented Aug 4 at 14:26
  • @aaa: correct, as long as you exclude bugs in the SSH implementation (which you do) and assume that the host key is not compromised. Note thought that someone with access to the server can still do traffic analysis of the encrypted traffic (but any host in the path of the connection could do this)
    – Steffen Ullrich
    Commented Aug 4 at 14:36
  • by host key you mean the key of the host I'm gonna SSH to, right? My computer key, not the intermediary server key
    – aaa
    Commented Aug 4 at 15:32
  • @aaa: correct, the host key of the final target system you trust, not the intermediate system.
    – Steffen Ullrich
    Commented Aug 4 at 15:45
  • 2
    @Nacht: This is true. But this is also true for any other system in between which provides the necessary connectivity. Thus it is not really specific to the SSH case in my opinion.
    – Steffen Ullrich
    Commented Aug 5 at 4:18
9

What you describe is called SSH tunneling and is a perfectly legitimate approach.

You don't have to trust the intermediate server when using an SSH tunnel. While it can see and manipulate all forwarded TCP traffic, the SSH protocol was specifically designed to work over a potentially insecure channel, so there's no risk with regard to confidentiality or integrity (excluding SSH vulnerabilities, of course). At best, the server could block the traffic.

However, the fact that the server can access internal network resources does put it in a critical position. There's nothing inherently wrong with this (it can actually be a security feature), and this isn't related to SSH in particular. But it means the server should be particularly well-protected to prevent attackers from gaining direct access to the internal resources. If you don't trust the server, then you probably shouldn't give it network access to your machines.

Improve this answer
4
  • What type of attack could be done if someone gains access to the server? The only exposed port is the SSH port on the target, which would already be exposed if I had a fixed IP at home
    – aaa
    Commented Aug 4 at 14:27
  • @aaa: If you compare an SSH tunnel with making the SSH port publicly accessible, then the tunnel is of course the more secure option, even if the intermediate server isn't trusted. My point is that an even better option would be a server which you do trust and which is under your control, because then you can make it more difficult for attackers to, for example, exploit vulnerabilities in SSH itself. So this isn't an argument against SSH tunneling, just for hardening the tunnel.
    – Ja1024
    Commented Aug 4 at 14:49
  • @Ja1024: But then you have to expose the trusted intermediary's SSH port to the internet, which is the same problem we set out to solve in the first place. This sounds like turtles all the way down.
    – Kevin
    Commented Aug 5 at 19:49
  • @Kevin: It’s not the same problem. First off, the OP’s goal was not to hide the SSH service altogether. If they had wanted that, then I would have suggested, for example, limiting it to a VPN. The goal was to not expose the local machines’ SSH service, and this is indeed solved with a jump host. Since that host’s single purpose is to act as an intermediate, it can be hardened by keeping all features to the absolute minimum, possibly using a mandatory-access-control module like SELinux or AppArmor, and not storing any sensitive assets (unlike the local machines).
    – Ja1024
    Commented Aug 5 at 20:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .