# [HOWTO?] SSH VPN - the real thing

## guero61

This is a log of my attempt to set up a *real* vpn using SSH's newfound tun/tap capability.  I may eventually care to script it and/or turn it into an official HOWTO, but for the moment I'm looking for feedback.  In fact, there's no guarantee this will work for anyone but myself.

Synopsis: use TAP devices over SSH, bridged with the production interface of the host in order to provide the (client-side) simplest, most effective SSH VPN possible.

===============================================

To start: make sure you have OpenSSH version 4.3 or above, and have the following directive in sshd_config of your server:

```

PermitTunnel yes

```

If you have just added that statement, please make sure you restart or SIGHUP your sshd, otherwise this won't work.

In addition, you need to make a bridge containing the interface you're ssh-ing into.  Complex, yes, but keep following

```

server# brctl addbr br0

server# brctl addif br0 eth0

server# ifconfig eth0 0 up

server# ifconfig br0 <original eth0 ip>

```

I'm not going into all the ins-and-outs of setting up bridging, but the core of the matter is that the way I'm going, you need the ability to seamlessly add clients onto the network.

Next, on the client side, add the following entry to ${HOME}/.ssh/config (or your favored location)

```

Host mysever.mydomain.com

    Tunnel ethernet

```

Discussion: most people do 'point-to-point' here, but I don't.  The reason is that I don't want to mess around with statically assigning addresses to both ends, plus the box that I'm actually SSHing into is not my router - it's port-forwarded, and I don't want to confuse my router/firewall by screwing around with multiple subnets, etc.

At this point, you need to make sure of two things: the TUN/TAP driver is loaded on both client & server, and /dev/net/tun is writable by you on both.  I've achieved this by editing /etc/udev/rules.d/50-udev.rules and changing the following:

```

KERNEL=="tun",      NAME="net/%k",  MODE="0600"

```

to the following:

```

KERNEL=="tun",      NAME="net/%k",  MODE="0660" GROUP="wheel"

```

That, of course, presumes you're in the 'wheel' group.  Pick your poison - you could even add a group 'sshvpn'; would make things easier (esp. for using sudo to configure the interfaces) in the long run.

At this point, the groundwork is laid; you're ready to initiate a connection:

```

client# ssh -w any myserver.mydomain.com

```

Once you log in successfully, the tunnel has been created, just not set up.  From the resulting prompt (on the server), issue the following commands:

```

server# ifconfig tap0 0 up

server# brctl addif br0 tap0

```

Again, that assumes you got the first TAP device.  YMMV, and that will increment with each consecutive tunnel created.  If the tapX device has not been created, something went wrong during the initialization; add the '-vv' flags to your ssh command and try again - you should get some information as to why the TUN/TAP device wasn't set up.

Now the choice is yours - you can statically configure the tapX device on the client side w/your choice of routes & go on, or follow me - I choose to route *ALL* of my traffic through this.

Client side:  In order to make sure the tunnel can continue, you need to make sure you have a route to the server's IP:

```

client# route add host <server IP> gw <current default gateway>

```

Here's the scary part, and the one where (if things go wrong), you'll lose comms and have to start over:

```

client# route del default

```

If you've configured tap0 with a static IP, set your default route accordingly; I prefer to let DHCP do that for me, since I have a DHCP server listening on that LAN:

```

client# dhcpcd tap0

```

That should be it.  At this point (barring any failures), you should now be routing all of your traffic through the destination host, onto it's LAN, and wherever from there you want it to go.  In fact, I'm posting this right now through such a setup.   :Wink: 

===================================

*whew*  Rather complex, I know.  OpenVPN was too touchy, and OpenSWAN too complex for my needs.  I know & understand OpenSSH, and this just seemed to make sense to me.  What do you guys think?  What did I leave out?  What can be explained more?

----------

## magic919

I think I'm happy with OpenVPN, however...

You might consider leaving baselayout to do some of the work.  It can handle bridges pretty well and is more Gentoo-style.

----------

## guero61

Absolutely - this was just the startup, the trip there.  I've already set up br0 in /etc/conf.d/net, set up an 'sshvpn' group, and generally cleaned things up a bit.  I've also used the LocalCommand directive from ssh_config to handle the host-side setup.  I may even work on setting up an event in udev to auto-dhcp tapX devices when they appear.

One thing I've noticed is that the tunnel remains up once you 'exit' from the remote shell - have to send an interrupt (ctrl-c) to actually stop the tunnel.

Don't get me wrong - I don't dislike OpenVPN or IPsec, but for my personal use SSH just fits better.  All the authentication hooks, auditing, support, and so on are already there.  It's been developed much farther, and I don't have to go use or set up yet another paradigm just to get a secure tunnel back home.

----------

## awies

Hi guero61,

 *guero61 wrote:*   

> 
> 
> Don't get me wrong - I don't dislike OpenVPN or IPsec, but for my personal use SSH just fits better.  All the authentication hooks, auditing, support, and so on are already there.  It's been developed much farther, and I don't have to go use or set up yet another paradigm just to get a secure tunnel back home.

 

... I realy love this howto.

The way you describe perfectly fits for me (even though I have to tunnel everything within another ssh-connection, as my ssh-gateway is not v4.3+), and makes life much more easier for me.

The way you describe your method is quite understandable.

I wonder why there's no better response from the forum.

IMHO, compared to openVPN, this setup is not too complex and helps you in a lot of conditions where you just can't have openVPN (although I agree this solution is not meant for replacing openVPN).

Great work, and I'm looking forward to see the gentoo-conformity-improvements  :Smile: ))

Cheers,

Armin

----------

## RockCrusha

indeed, well done.  

perfect for me to help get this set up on other distros as well as Gentoo.

Thanks

----------

## guero61

This is still on my plate to script up and likely package - there are just other things in it's way right now.

----------

