1

In the local port forwarding invocation below,

[me@TunnelBeginHost]$ ssh -L TunnelBeginPort:TunnelEndHost:TunnelEndPort ViaUser@ViaHost

, given the fact that the portion of the tunnel between ViaHost and TunnelEndHost is insecure, prone to network sniffing and all that, why is ssh even providing such an option? Security being at the heart of ssh, shouldn't it have required authentication at the TunnelEndHost as well..., say with a (hypothetical) syntax such as,

[me@TunnelBeginHost]$ # Proposed syntax:
[me@TunnelBeginHost]$ ssh -L TunnelBeginPort:TunnelEndUser:TunnelEndHost:TunnelEndPort ViaUser@ViaHost

that would have ensured a secure tunnel between ViaHost and TunnelEndHost as well?

Likewise, for remote port forwarding.

Understanding the rationale behind this capability of ssh will help clear up any misconceptions I may have about ssh-tunneling, or about security caveats associated with it.

0

3 Answers 3

2

First, "the portion of the tunnel between ViaHost and TunnelEndHost is insecure" is not a fact. You assume that the end host will be connected over public Internet, but that's not always the case – I might be using the tunnel for HTTPS, it might be going over IPsec, an encrypted VPN, or just a physically secured cable connection. My virtual machine LAN is not prone to sniffing as long as I'm the only one having root on my own laptop.

Second, what @Xeross said – how would you authenticate in your proposed scheme? Using what protocol? The tunnel feature was created to support arbitrary TCP connections. What if the end host does not support SSH, or TLS, or your favourite protocol? If you decided to require SSH support on the end host, then the entire tunnel feature becomes practically useless as the user could just SSH to the end host directly.

Finally, why not? ssh cannot know the user's network conditions better than the user themself (as seen in the first paragraph), and adding arbitrary restrictions such as this might just hinder their work. ssh is here to help, but not to babysit, as is the tradition of Unix programs.

3
  • I'm assuming that (1) the network traffic to/from TunnelEndHost can be sniffed even if it be on regular, non-IPsec intranet; (2) the TunnelEndHost has sshd running, and that the command in the syntax proposed above would fail if not. Isn't it true that (insecure) TCP tunnels could also be created via a program like socat, so why should ssh volunteer for an insecure functionality as this?
    – Harry
    Jun 18, 2012 at 10:09
  • "...the entire tunnel feature becomes practically useless as the user could just SSH to the end host directly." Not sure I follow you. The client and the server which are being connected via this tunnel may be inherently insecure, so having ssh on the endpoint would still help.
    – Harry
    Jun 18, 2012 at 10:11
  • @Harry: "I'm assuming that ..." You are assuming arbitrary conditions again, and these assumptions are false for very many use cases. Jun 18, 2012 at 10:13
0

How exactly would this end-point authentication work, considering the end-point could be anything, HTTP, HTTPS, etc. (you get the idea).

If the traffic needs to be encrypted whatever protocol you're trying to send over the tunnel will have to take care of that itself.

7
  • The end-point authentication would work the same way it works for ViaUser@ViaHost, only that it would ask for 2 passwords: one for authenticating ViaUser@ViaHost (and it already does that presently), and another for authenticating TunnelEndUser@TunnelEndHost.
    – Harry
    Jun 18, 2012 at 9:59
  • @Harry: What if you're tunneling something other than SSH? Jun 18, 2012 at 10:06
  • @grawity Why do you ask this only in case of off-host forwarding?
    – Harry
    Jun 18, 2012 at 11:43
  • @Harry because that's the case where you can't authenticate with SSH on the destination because the destination isn't SSH Jun 18, 2012 at 12:06
  • "because the destination isn't SSH" In which case SSH shouldn't offer to build the tunnel to the destination. I guess, that was the whole point of my original question; namely: If SSH can't provide a secure end-to-end tunnel, then it shouldn't try to provide a part-secure-and-part-insecure one. OTOH, it could try to provide a secure end-to-end tunnel with an extra SSH authentication for the tunnel end-point as well. Insecure tunnels one could always build with socat.
    – Harry
    Jun 18, 2012 at 15:37
-2

Off-host forwarding is a part secure and part insecure feature of ssh, making it overall an insecure feature.

The man page of ssh must include an explicit caveat regarding this. Regrettably, it does not, as of version openssh-clients-5.8p2-25.fc16.i686.

0

You must log in to answer this question.

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