OpenSSH VPN between Mac OS X and OpenBSD

Chris Rapier
2006-02-10T15:27:34Z

Honestly, I'm probably not the best person to ask this. I really just
deal with network performance issues. You should try the OpenSSH
development group. I've cc:'d that group on this message.

However, a quick look at the code shows that you'd only be getting that
warning if both CUSTOM_SYS_TUN_OPEN and SSH_TUN_OPENBSD are not defined.
Grep on the first define we find the following in the change log

(djm) [misc.c] Disable tunnel code for non-OpenBSD (for now), enable
again by providing a sys_tun_open() function for your platform and
setting the CUSTOM_SYS_TUN_OPEN define. More work is required to match
OpenBSD's tunnel protocol, which prepends the address family to the packet

Then on the 20060101 there is a note mentioning support for NetBSD and
FreeBSD. But thats about it. No mention of OS X or linux.

So... I don't know what this means in terms of what it can or cannot do
but the people on the dev list can tell you for sure.

Chris Rapier
Pittsburgh Supercomputing Center


Johan Berg wrote:
> Howdy,
>
> I recently tried to get OpenSSH 4.3 (built on darwinports) and
OpenBSD's
> OpenSSH 4.3 (OpenBSD as the server) with VPN working. I get stuck when
> I've created the tun interfaces on both sides and everything seems OK.
> Tiger doesn't come with tun/tap support so I had to get
> http://www-user.rhrk.uni-kl.de/~nissler/tuntap/.
>
> PermitTunnel is set to yes and tun0 got:
>
> tun0: flags=51<UP,POINTOPOINT,RUNNING> mtu 3000
>         groups: tun
>         inet 192.168.1.1 --> 192.168.1.2 netmask 0xfffffffc
>
>
>
> I tried the following from my Mac, with -v:
>
> voltaire ~ # ssh -vfw 0:1 argus true
> OpenSSH_4.3p1, OpenSSL 0.9.8 05 Jul 2005
> debug1: Reading configuration data /Users/johan/.ssh/config
> debug1: Applying options for argus
> debug1: Reading configuration data /opt/local/etc/ssh/ssh_config
> debug1: Connecting to argus [192.168.0.254] port 22.
> debug1: Connection established.
> debug1: identity file /Users/johan/.ssh/identity type -1
> debug1: identity file /Users/johan/.ssh/id_rsa type 1
> debug1: identity file /Users/johan/.ssh/id_dsa type -1
> debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
> debug1: match: OpenSSH_4.3 pat OpenSSH*
> debug1: Enabling compatibility mode for protocol 2.0
> debug1: Local version string SSH-2.0-OpenSSH_4.3
> debug1: SSH2_MSG_KEXINIT sent
> debug1: SSH2_MSG_KEXINIT received
> debug1: kex: server->client aes128-cbc hmac-md5 none
> debug1: kex: client->server aes128-cbc hmac-md5 none
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
> debug1: Host 'argus' is known and matches the RSA host key.
> debug1: Found key in /Users/johan/.ssh/known_hosts:33
> debug1: ssh_rsa_verify: signature correct
> debug1: SSH2_MSG_NEWKEYS sent
> debug1: expecting SSH2_MSG_NEWKEYS
> debug1: SSH2_MSG_NEWKEYS received
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug1: Next authentication method: publickey
> debug1: Trying private key: /Users/johan/.ssh/identity
> debug1: Offering public key: /Users/johan/.ssh/id_rsa
> debug1: Server accepts key: pkalg ssh-rsa blen 277
> debug1: read PEM private key done: type RSA
> debug1: Authentication succeeded (publickey).
> debug1: channel 0: new [client-session]
> debug1: Entering interactive session.
> debug1: Requesting tun.
> Tunnel interfaces are not supported on this platform
> debug1: Sending command: true
> debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
> debug1: channel 0: free: client-session, nchannels 1
> debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds
> debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
> debug1: Exit status 0
>
> Any idea what might cause "Tunnel interfaces are not supported on this
> platform", is the tuntap install package broken in some way or is SSH
> trying to create a new tun interface which can't be made?
>
> Regards,
>
>     -- Johan Berg
>
>