OpenBSD Journal

OpenSSH small tunneling improvement patch

Contributed by jose on from the testing-patchwork dept.

Jonatan Wallmander writes: "We had this problem: -g i the ssh client exports the tunnel on INADDR_ANY. We've written a small and simple patch which adds -G which lets you bind to a specific address. Now interface aliases (i.e. extra IP addresses on the client exporting the tunnel) can be bound to different ssh tunnels.

Finally a single BSD box can act as a VPN gateway for more than one computer on the internet/LAN. This is perfect for accessing data on remote production servers over samba tunneled from the loopback addr.

Could this be a good future feature for OpenSSH?

Our little report and OpenBSD patch along with some ssh tunneling help for da noobies (like myself) is here: http://research.vovoid.com

Enjoy :)

/The furries at Vovoid Software & Multimedia" Looks interesting. Obviously this is an unofficial patch, but if you're feeling like testing something out this may be useful to you.

(Comments are closed)


Comments
  1. By Anonymous Coward () on

    Interesting read. This is all fine and dandy if you use Samba, but can SSH be used to tunnel other things? & more importantly, can it be used to VPN with similar functionality to IPSec/ISAKMPD where it would tunnel all traffic from one host to another securely, not just traffic on a certain port?

    Comments
    1. By jonatan wallmander () jonatan@vovoid.com on http://www.vovoid.com

      Yes. however not all ports. you have to give extra -L arguments. then you can tunnel HTTP, ftp or NS.. for testing out servers not launched that could be a very nice thing...

      Comments
      1. By blkwolf () on http://blkwolf.dyn.ca

        You can also use the -D switch to make ssh act as a socks4 proxy. Then any program that can talk socks can be routed over the tunnel

    2. By nickf3 () on

      With OBSD's excellent ipsec support why would you want to use ssh for tunneling?

  2. By Charles Hill () charles.e.hill@attbi.com on mailto:charles.e.hill@attbi.com

    Using SSH as a full-blown VPN has been discussed many times elsewhere.

    The big issue that keeps popping up is that SSH is TCP only, and won't truely tunnel UDP. You then end up with TCP over TCP which has generated a lot of heat in the arguments. Extra TCP ACKs, and TCP retransmission are the likely culprits.

    SSH thru NAT is a real pain, whereas IPSec has an actual IETF drafts covering it. And it works -- I've done it on a daily basis with different vendors hardware/software.

    SSH doesn't really have any sort of key exchange mechanism like IKE for IPSec.

    Whiles adding the ability to specify the port used will be great -- don't let it fool you into thinking SSH is a full-blown VPN. That wasn't what it was designed for.

    Comments
    1. By mra () on

      SSH thru NAT is a real pain Huh?!
      I cross NAT boundaries all the time with SSH. The only issue I've ever run into is that the NAT be setup to send SSH to the right place. This is hardly SSHs fault, it is a configuration issue with NAT.
      I certainly agree with you that SSH isn't, and shouldn't be, a VPN, but blaming SSH for an issue that is intrinsically part of NAT seems misplaced.
      As for key exchange there are some mechanisms being drafted in the IETF right now to help with that. Granted they are storing the host keys in DNS, and this gets into other issues, but it should further reduce the threat from MitM attacks. Personally I find that using user based public/private keypairs is the best way around this issue. If you get a password prompt instead of the pubkey you were expecting you know something is not right.

    2. By grey () on

      I have to second mra a bit here. I can't think of 0 problems I've ever encountered using ssh through a standard NAT.

      Meanwhile, dealing with particular vendor NAT and IPSec implementations I continually run into [just to pull some names that steal my time when I need to walk a user through setting up a VPN connection how about: Checkpoint VPN-1 paired with Windows SecuRemote paired with a Linksys home DSL 'router' doing braindead NAT - and trying to explain to Joe Consumer User how to turn on port forwarding on their "router's" web GUI isn't as straight forward as it should be either]. And that's even when things are set up to only use ESP (are there IETF drafts for AH + NAT traversal? I haven't paid attention in a while). The VPN industry is having a field day with new products touting "NAT traversal" because most vendors didn't get it right the first time around.

      Keep in mind, the VPN world is -primarily- [not exclusively] oriented at windows users as well. There aren't many unix applications that can't be run from a terminal as provided by ssh.

      And, really IPSec is complete overkill for a lot of things. In this case, if you only want to do port forwarding - building a whole tunnel, dealing with policies and so on is a waste, the default use of ssh already allows for a simple solution to tunnelling just smb, and this paper merely builds upon that slightly.

      IPSec still has its place, and should really be used more widely. But, just because IPSec makes more sense for some things doesn't mean that it should always be used. Case in point, for say 802.11 IPSec is a perfect fit but instead we have EAP and LEAP and now WPA to replace WEP. But that doesn't mean that it's always a good fit. There are many applications for which ssh or stunnel and the like are more than sufficient.

      A bigger problem to bitch about (vs say using ssh or IPSec) is that vendors should be picking the right tool to use as an encryption layer from the get go, and making it mandatory and thus transparent. Instead we get protocol after protocol which just didn't even think about security. And then, when the finally do, they tend to reinvent the wheel instead of making use of what is already out there. I'd bitch to no end on things like that. The less time I need to waste as an admin setting up and configuring individual clients, or talking users through problems which they don't even understand the better; the VPN industry still has a long way to go there. Meanwhile for _certain_ things, ssh (and by extension scp) is just transparent to the user, it's just another application they run, security is more or less accounted for, and there are no gotchas.

      Sorry, I did get off into that bitch a little bit longer than expected. Vendors should be tunnelling things to begin with (I think I've seen a VNC release out there which automatically tunnels with ssh), making it optional in a non-default behaviour. (I'll shut up now)

      Comments
      1. By andy () on

        "IPSec still has its place, and should really be used more widely. But, just because IPSec makes more sense for some things doesn't mean that it should always be used. Case in point, for say 802.11 IPSec is a perfect fit but instead we have EAP and LEAP and now WPA to replace WEP. But that doesn't mean that it's always a good fit. There are many applications for which ssh or stunnel and the like are more than sufficient.
        "

        EAP-TLS is a pain in the ass to work with an openbsd server with freeradius and he just support XP and windows 2k is not so easy with xsuplicant for BSD and linux.
        wpa is just not widely deployed.
        security on 802.11b ...not an easy job to support connection and security for the masses

    3. By djm () on

      > SSH doesn't really have any sort of key
      > exchange mechanism like IKE for IPSec

      Actually, it does.

  3. By markus () markus@openbsd.org on mailto:markus@openbsd.org

    both -L and -R will be extended to allow
    -L laddr:lport:raddr:rport,

    http://bugzilla.mindrot.org/show_bug.cgi?id=413

    and perhaps other protocols.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]