OpenSSH on R7000

From DD-WRT Wiki

(Difference between revisions)
Jump to: navigation, search
Revision as of 01:04, 28 February 2014 (edit)
Magick777 (Talk | contribs)
(Wrapper scripts / general background reading)
← Previous diff
Revision as of 02:50, 28 February 2014 (edit) (undo)
Magick777 (Talk | contribs)
(Client configuration)
Next diff →
Line 88: Line 88:
=== Client configuration === === Client configuration ===
-You will almost certainly want to have set up passwordless, public-key based SSH access between client and server before you try to use it for VPN purposes. +You will almost certainly want to have set up passwordless, public-key based SSH access between client and server before you try to use it for VPN purposes. Put your public key into the relevant section of the DD-WRT web interface to have it stored in nvram and copied to the right place on startup. You will also want to be sure that on your client, you have OpenSSH client v4.3 or newer, root access, ability to create tun/tap interfaces, and use of routing tools.
==== Wrapper scripts & general background reading ==== ==== Wrapper scripts & general background reading ====
See [https://github.com/halhen/pvpn pvpn] for a wrapper script that supports two approaches to VPN over SSH; it can use the OpenSSH Layer 3 VPN built into versions 4.3 and newer and/or it can use PPP over SSH (you'll need pppd at both ends, of course). See also [https://github.com/bocadillodeatun/start_vpn start_vpn.sh], but don't expect either of these to work out of the box. Also read [http://backreference.org/2009/11/13/openssh-based-vpns/ OpenSSH-based VPNs], which provides a good overview of what we're trying to do. See [https://github.com/halhen/pvpn pvpn] for a wrapper script that supports two approaches to VPN over SSH; it can use the OpenSSH Layer 3 VPN built into versions 4.3 and newer and/or it can use PPP over SSH (you'll need pppd at both ends, of course). See also [https://github.com/bocadillodeatun/start_vpn start_vpn.sh], but don't expect either of these to work out of the box. Also read [http://backreference.org/2009/11/13/openssh-based-vpns/ OpenSSH-based VPNs], which provides a good overview of what we're trying to do.
 +
 +===== Bridged VPN =====
 +
 +The most typical use case with DD-WRT is for a bridged VPN, which means that the client, when connected, is bridged to the local LAN as though it were physically plugged into an Ethernet port. The client should receive an IP address from the DHCP server on the local LAN in the usual way if it requests one via DHCP, and should be able to reach everything on the LAN as if it were plugged in directly.
 +
 +To make that happen, we'll need a layer-2 tunnel (i.e. tap interfaces at both ends) per client; at the server end on DD-WRT, this interface will be added into the existing LAN bridge br0, which is already a bridge of the wired Ethernet ports and the wireless Ethernet adaptors on the router. Think of it as plugging an additional virtual network adaptor into that bridge, and using a layer 2 VPN (over SSH, over TCP/IP) as the virtual "cable". On the client end of that "cable", we have to configure our new virtual network adaptor exactly like we'd configure a physical one: either provide it with static IP address and routing settings, or run a DHCP client on it to achieve the same via dynamic host configuration.
 +
 +<strike>Basing ourselves on that HOWTO, we first need to create the tap devices. On DD-WRT, I had no luck with "ip tuntap add tap140 mode tap" (our ip command doesn't seem to support it), no luck with tunctl (not present), no luck installing either from Optware - but, we have an OpenVPN binary, and it can be used to create tun/tap interfaces for us, so let's resort to that. Assume that all commands are to be run on the *client*; where we need to set things up on the router, we do that over SSH.
 +
 + ssh root@router "openvpn --rmtun --dev tap140 && openvpn --mktun --dev tap140 && brctl addif br0 tap140 && brctl show"
 +
 +should get us a tap interface configured and bridged on DD-WRT; the choice of tap140 was arbitrary, and reflects a local IP address that I happen to associate with the client I propose to use. One could organise to randomise this, or randomise it and check what's already in use, if one had many parallel clients. For me, assigning an interface to a given client is fine.
 +
 +On the client (Nokia N900, Maemo 5), we need to create the tap interface in similar fashion
 +
 + openvpn --rmtun --dev tap140 && openvpn --mktun --dev tap140 && ifconfig tap140
 +
 +Now, we should be able to connect the two tunnels using OpenSSH layer 2 VPN:
 +</strike>
 +
 +The HOWTO is outdated; SSH will create the tap interfaces for you on the fly.
 +
 +
 +
[[Category:R7000]] [[Category:R7000]]

Revision as of 02:50, 28 February 2014

Contents

Use cases for OpenSSH

For regular SSH/SFTP access to the router, DD-WRT's built-in dropbear SSH client and server are perfectly adequate. However, OpenSSH offers a few useful features over and above dropbear, specifically

  • SOCKS5 proxy over SSH
  • PPP connections over SSH
  • VPN connections over SSH

Installing OpenSSH

Prerequisites

You will need to install the packages from a compatible Optware repository. OpenSSH packages are available in the imx6 repository; the latest version of OpenSSH is in magick's devel repo. Make sure that you have Optware working properly and can install packages successfully.

Client

If all you want is the client, then it is easily installed with

opkg install openssh-client

This will be sufficient to enable you to create an on-the-fly SOCKS5 proxy on the router, connected to the SSH server of your choice. You may wish to look at public key authentication, server keep alive, and the reconnect option, if you want this connection to be permanent.

Server

Installing the OpenSSH server is slightly more complicated. First, let's relocate dropbear to another port so we don't lose SSH access.

Change the dropbear port

You can change the port that dropbear listens on with:

nvram set sshd_wanport=2222
nvram set sshd_port=2222
stopservice sshd
startservice sshd

As this will disconnect your SSH connection, you can also paste these commands into the Web interface and click Run Commands, then SSH to the router on port 2222 to check that it worked. If it did, we now have port 22 free for OpenSSH.

Install and configure the OpenSSH server

opkg update
opkg install openssh-server
sshd_config

Now, edit /opt/etc/ssh/sshd_config to your requirements. Most of the defaults should be OK, but some things I changed included:

  • have it use the same host keys as dropbear (in /tmp/root/.ssh)
    • dropbearconvert dropbear openssh /tmp/root/.ssh/ssh_host_rsa_key /tmp/root/.ssh/openssh_host_rsa_key
    • dropbearconvert dropbear openssh /tmp/root/.ssh/ssh_host_dss_key /tmp/root/.ssh/openssh_host_dsa_key
    • put the latter filenames in sshd_config
    • the keys are in /tmp, written from nvram, so we'll need to perform the key conversions on every startup
  • turned on ClientAliveInterval 60 and ClientAliveCountMax 3
  • turned on PermitTunnel
  • commented out the SFTP subsystem as we haven't installed it yet
  • set UsePrivilegeSeparation no, we don't have an sshd user and will run as root
start sshd manually

To start sshd, the command line we need is

LD_LIBRARY_PATH=/opt/usr/lib /opt/usr/sbin/sshd -f /opt/etc/ssh/sshd_config

which points it to the correct OpenSSL version and the desired config file. If all is well, this should return without error, your sshd process should be listening on port 22 and you should be able to gain SSH access to the router on port 22 using your normal credentials.

enable SFTP subsystem

So far, so good, but whilst this enables some new functionality, it is currently a regression as compared with dropbear, because SFTP doesn't work. Fix that with:

opkg install openssh-sftp-server

then edit sshd_config to enable the SFTP subsystem and point it to /opt/usr/lib/sftp-server - you should now find that SFTP works as well. Issue a SIGHUP to sshd to reload the config file, of course.

start sshd automatically on startup

To have the OpenSSH server run automatically on DD-WRT startup, we need to convert the dropbear keys supplied by DD-WRT, and then run the required command line. Adding

dropbearconvert dropbear openssh /tmp/root/.ssh/ssh_host_rsa_key /tmp/root/.ssh/openssh_host_rsa_key
dropbearconvert dropbear openssh /tmp/root/.ssh/ssh_host_dss_key /tmp/root/.ssh/openssh_host_dsa_key
LD_LIBRARY_PATH=/opt/usr/lib /opt/usr/sbin/sshd -f /opt/etc/ssh/sshd_config

to your DD-WRT startup commands should do the trick, and you should now have a fully functional OpenSSH server on port 22.

Using OpenSSH for VPN connections

Server & account configuration

You'll want PermitTunnel enabled in your sshd_config, and you will need to be root at both ends of the connection if you intend to create tunnels and change routes on the fly.

Client configuration

You will almost certainly want to have set up passwordless, public-key based SSH access between client and server before you try to use it for VPN purposes. Put your public key into the relevant section of the DD-WRT web interface to have it stored in nvram and copied to the right place on startup. You will also want to be sure that on your client, you have OpenSSH client v4.3 or newer, root access, ability to create tun/tap interfaces, and use of routing tools.

Wrapper scripts & general background reading

See pvpn for a wrapper script that supports two approaches to VPN over SSH; it can use the OpenSSH Layer 3 VPN built into versions 4.3 and newer and/or it can use PPP over SSH (you'll need pppd at both ends, of course). See also start_vpn.sh, but don't expect either of these to work out of the box. Also read OpenSSH-based VPNs, which provides a good overview of what we're trying to do.

Bridged VPN

The most typical use case with DD-WRT is for a bridged VPN, which means that the client, when connected, is bridged to the local LAN as though it were physically plugged into an Ethernet port. The client should receive an IP address from the DHCP server on the local LAN in the usual way if it requests one via DHCP, and should be able to reach everything on the LAN as if it were plugged in directly.

To make that happen, we'll need a layer-2 tunnel (i.e. tap interfaces at both ends) per client; at the server end on DD-WRT, this interface will be added into the existing LAN bridge br0, which is already a bridge of the wired Ethernet ports and the wireless Ethernet adaptors on the router. Think of it as plugging an additional virtual network adaptor into that bridge, and using a layer 2 VPN (over SSH, over TCP/IP) as the virtual "cable". On the client end of that "cable", we have to configure our new virtual network adaptor exactly like we'd configure a physical one: either provide it with static IP address and routing settings, or run a DHCP client on it to achieve the same via dynamic host configuration.

Basing ourselves on that HOWTO, we first need to create the tap devices. On DD-WRT, I had no luck with "ip tuntap add tap140 mode tap" (our ip command doesn't seem to support it), no luck with tunctl (not present), no luck installing either from Optware - but, we have an OpenVPN binary, and it can be used to create tun/tap interfaces for us, so let's resort to that. Assume that all commands are to be run on the *client*; where we need to set things up on the router, we do that over SSH.

ssh root@router "openvpn --rmtun --dev tap140 && openvpn --mktun --dev tap140 && brctl addif br0 tap140 && brctl show"

should get us a tap interface configured and bridged on DD-WRT; the choice of tap140 was arbitrary, and reflects a local IP address that I happen to associate with the client I propose to use. One could organise to randomise this, or randomise it and check what's already in use, if one had many parallel clients. For me, assigning an interface to a given client is fine.

On the client (Nokia N900, Maemo 5), we need to create the tap interface in similar fashion

openvpn --rmtun --dev tap140 && openvpn --mktun --dev tap140 && ifconfig tap140

Now, we should be able to connect the two tunnels using OpenSSH layer 2 VPN:

The HOWTO is outdated; SSH will create the tap interfaces for you on the fly.