Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question
add comment

3 Answers

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.

share|improve this answer
    
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 '12 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 '12 at 10:11
    
@Harry: "I'm assuming that ..." You are assuming arbitrary conditions again, and these assumptions are false for very many use cases. –  grawity Jun 18 '12 at 10:13
    
Thanks for wording it better. –  Xeross Jun 18 '12 at 13:51
add comment

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.

share|improve this answer
    
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 '12 at 9:59
    
@Harry: What if you're tunneling something other than SSH? –  grawity Jun 18 '12 at 10:06
    
@grawity Why do you ask this only in case of off-host forwarding? –  Harry Jun 18 '12 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 –  Xeross Jun 18 '12 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 '12 at 15:37
show 2 more comments
up vote -2 down vote accepted

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.