# Does ssh tunnel require tun/tap driver in kernel? [solved]

## turtles

Does a ssh tunnel require tun/tap driver in kernel?

Thanks

(Trying to set up a non root ssh tunnel)

----------

## Hu

It would be easier for you to try what you want and report back than for you to ask us, since there are several ways the question could be interpreted.  You might be asking about simple ssh port forwarding, which never requires kernel support, but does respect usual port listener rules.  You could be asking about the ad hoc VPN support based on the TUN/TAP device, which requires both kernel support and permission to access it.  Such permission is normally available only to root, although root can grant unprivileged users access to a TUN/TAP device.  You could be using tunnel in one of the less common ways, such as referring to tunneling an ssh connection through an intermediate host to get to the desired endpoint.

----------

## turtles

Sorry for being vague hu.

I am trying to work remotely on a postgress DB

http://www.postgresql.org/docs/8.2/static/ssh-tunnels.html

I run the command:

```
ssh -vvL 3333:XXXXXXXXX.com:5432 XXXXXXXXXX.com
```

```

OpenSSH_5.9p1-hpn13v11, OpenSSL 1.0.1c 10 May 2012

debug1: Reading configuration data /root/.ssh/config

debug1: /root/.ssh/config line 22: Applying options for XXXXXXXX

debug1: Reading configuration data /etc/ssh/ssh_config

debug2: ssh_connect: needpriv 0

debug1: Connecting to .XXXXXXXXXX.com

debug1: Connection established.

debug1: permanently_set_uid: 0/0

debug1: identity file /root/.ssh/id_new_rsa type 1

debug1: identity file /root/.ssh/id_new_rsa-cert type -1

debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9p1-hpn13v11

debug1: match: OpenSSH_5.9p1-hpn13v11 pat OpenSSH*

debug1: Enabling compatibility mode for protocol 2.0

debug1: Local version string SSH-2.0-OpenSSH_5.9p1-hpn13v11

debug2: fd 3 setting O_NONBLOCK

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: AUTH STATE IS 0

debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa-cert-v01@openssh.com,ssh-rsa-cert-v00@openssh.com,ssh-rsa,ssh-dss-cert-v01@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-dss

debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: first_kex_follows 0 

debug2: kex_parse_kexinit: reserved 0 

debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256

debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96

debug2: kex_parse_kexinit: none,zlib@openssh.com

debug2: kex_parse_kexinit: none,zlib@openssh.com

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: 

debug2: kex_parse_kexinit: first_kex_follows 0 

debug2: kex_parse_kexinit: reserved 0 

debug2: mac_setup: found hmac-md5

debug1: REQUESTED ENC.NAME is 'aes128-ctr'

debug1: kex: server->client aes128-ctr hmac-md5 none

debug2: mac_setup: found hmac-md5

debug1: REQUESTED ENC.NAME is 'XXXXX'

debug1: kex: client->server aes128-ctr hmac-md5 none

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP

debug2: dh_gen_key: priv key bits set: 116/256

debug2: bits set: 547/1024

debug1: SSH2_MSG_KEX_DH_GEX_INIT sent

debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY

debug1: Server host key:XXXX

debug1: Host 'XXXX' is known and matches the RSA host key.

debug1: Found key in X

debug2: bits set: 503/1024

debug1: ssh_rsa_verify: signature correct

debug2: kex_derive_keys

debug2: set_newkeys: mode 1

debug1: SSH2_MSG_NEWKEYS sent

debug1: expecting SSH2_MSG_NEWKEYS

debug2: set_newkeys: mode 0

debug1: SSH2_MSG_NEWKEYS received

debug1: Roaming not allowed by server

debug1: SSH2_MSG_SERVICE_REQUEST sent

debug2: service_accept: ssh-userauth

debug1: SSH2_MSG_SERVICE_ACCEPT received

debug2: key: XXXX

debug1: Authentications that can continue: publickey,keyboard-interactive

debug1: Next authentication method: publickey

debug1: Offering RSA public key: /root/.ssh/XXXX

debug2: we sent a publickey packet, wait for reply

debug1: Server accepts key: pkalg ssh-rsa blen 279XXXXXX

XXXX

debug1: read PEM private key done: XXXXX

debug1: Authentication succeeded (publickey).

Authenticated to XXXXXXX

debug1: Local connections to LOCALHOST:3333 forwarded to remote address XXXXXXX:5432

debug1: Local forwarding listening on ::1 port 3333.

debug2: fd 4 setting O_NONBLOCK

debug1: channel 0: new [port listener]

debug1: Local forwarding listening on 127.0.0.1 port 3333.

debug2: fd 5 setting O_NONBLOCK

debug1: channel 1: new [port listener]

debug1: Requesting tun unit 2147483647 in mode 1
```

Interesting part of log next:

debug1: sys_tun_open: failed to open tunnel control interface: No such file or directory

rest of log:

```
Tunnel device open failed.

Could not request tunnel forwarding.

debug1: Final hpn_buffer_size = 131072

debug1: HPN Disabled: 0, HPN Buffer Size: 131072

debug1: channel 2: new [client-session]

debug1: Enabled Dynamic Window Scaling

debug2: channel 2: send open

debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

debug2: callback start

debug1: Requesting authentication agent forwarding.

debug2: channel 2: request auth-agent-req@openssh.com confirm 0

debug2: client_session2_setup: id 2

debug2: fd 3 setting TCP_NODELAY

debug2: channel 2: request pty-req confirm 1

debug2: channel 2: request shell confirm 1

debug2: callback done

debug2: channel 2: open confirm rwindow 0 rmax 32768

debug2: tcpwinsz: 87380 for connection: 3

debug2: tcpwinsz: 87380 for connection: 3

debug2: channel_input_status_confirm: type 99 id 2

debug2: PTY allocation request accepted on channel 2

debug2: channel 2: rcvd adjust 87380

debug2: channel_input_status_confirm: type 99 id 2

debug2: shell request accepted on channel 2

debug2: tcpwinsz: 87380 for connection: 3

debug2: tcpwinsz: 87380 for connection: 3

Last login: Mon Jul 15 20:58:11 PDT 2013 from XXX

debug2: tcpwinsz: 87380 for connection: 3

debug2: tcpwinsz: 87380 for connection: 3

debug2: tcpwinsz: 87380 for connection: 3

debug2: tcpwinsz: 87380 for connection: 3

```

I dont have the tun/tap module installed.

I obviously get in to the remote server and can start a psql shell as my normal user.

i do not have root access to the psql server.

i do locally have root access on my laptop  :Smile:  thanks

----------

## imaginasys

Are you getting the second log when you try to connect with plsql ? with the command "psql -h localhost -p 3333 postgres" ???

The first part show that you have succeded your connection between your machine to the posgress DB server.

The second part show that you cannot authenticate to the postgress server.  You seems to be logging as "root@xxxxxx.com", is root a legal user for the postgress DB ?

You need to use a legal postgress user to log.  And the ssh server need to be on the same machine that the postgress DB server.

Just my 0,02$,

     Regards,

                    BT    :Mr. Green: 

----------

## turtles

 *imaginasys wrote:*   

> Are you getting the second log when you try to connect with plsql ? 

 

No I broke up the ssh log. That error is ssh complaining that it cant open the tunnel device (in /dev i think)

I was able to build and load the tun kernel module on both ends.

I now can see the 

```
crw-rw-rw- 1 root root 10, 200 Jul 15 23:06 /dev/net/tun

```

 tunnel device in /dev

but I need to access it as a non root user.

now I get:

```
debug1: Requesting no-more-sessions@openssh.com

debug1: Entering interactive session.

debug1: Remote: Failed to open the tunnel device.

channel 2: open failed: administratively prohibited: open failed

debug1: Requesting authentication agent forwarding.

```

EDIT adding info:

 relevant config ssh_config on client:

```
    

Tunnel yes

#   TunnelDevice any:any

```

and on server:

```
PermitTunnel yes
```

----------

## mike155

You definitely don't need tun/tap devices for 'ssh -L 3333:XXXXXXXXX.com:5432 XXXXXXXXXX.com'. You need tun/tap devices if you want to run a virtual machine on your server.

Look at ' /etc/ssh/sshd_config' on XXXXXXXXXX.com: 'AllowTcpForwarding' must be set to 'yes'.

Most probably, your SSH command should be 'ssh -L 3333:127.0.0.1:5432 XXXXXXXXXX.com' if your PostgreSQL database runs on XXXXXXXXXX.com. This depends

on the configuration of your PostgreSQL database server.

----------

## turtles

 *bug_report wrote:*   

> You definitely don't need tun/tap devices for 'ssh -L 3333:XXXXXXXXX.com:5432 XXXXXXXXXX.com'. You need tun/tap devices if you want to run a virtual machine on your server.
> 
> Look at ' /etc/ssh/sshd_config' on XXXXXXXXXX.com: 'AllowTcpForwarding' must be set to 'yes'.
> 
> Most probably, your SSH command should be 'ssh -L 3333:127.0.0.1:5432 XXXXXXXXXX.com' if your PostgreSQL database runs on XXXXXXXXXX.com. This depends
> ...

 

AAH thanks bug_report ! That was it. The command I needed was 

```
ssh -vL 3333:localhost:5432 XXXXXXXXXX.com
```

Now I get this log:

```
debug1: Entering interactive session.

debug1: Remote: Failed to open the tunnel device.

channel 2: open failed: administratively prohibited: open failed

debug1: Requesting authentication agent forwarding.

debug1: channel 2: free: tun, nchannels 4

debug1: Connection to port 3333 forwarding to localhost port 5432 requested.

debug1: channel 2: new [direct-tcpip]

debug1: channel 2: free: direct-tcpip: listening port 3333 for localhost port 5432, connect from ::1 port 42500, nchannels 4

debug1: Connection to port 3333 forwarding to localhost port 5432 requested.

debug1: channel 2: new [direct-tcpip]

```

In order to better my understanding of ssh tunnels what is the  "Remote tunnel device" it cant open however still succeeds?

----------

## mike155

The important message is 'channel 2: open failed: administratively prohibited: open failed'. Please look at the SSH daemon config on your PostgreSQL Server, especially the parameter AllowTcpForwarding. Most probably, port forwarding is not allowed - and in this case you get exactly this message. 

I cannot say anything about the messages containing 'tun' or 'tunnel'. I don't see those messages on my systems.

----------

## turtles

 *bug_report wrote:*   

> The important message is 'channel 2: open failed: administratively prohibited: open failed'. 

 

That is gone now I can tunnel successfully that I use:

```
 ssh -vL 5432:localhost:5432 me@XXXXX.com
```

the 127.0.0.1 did not work.

Thanks Again !

 *bug_report wrote:*   

> I cannot say anything about the messages containing 'tun' or 'tunnel'. I don't see those messages on my systems.

 

If you use the -v debugging switch you will see it. 

I just wonder what it means perhaps ill look in the code when I can.

Also a note for others with the same problem:

The "administratively prohibited" in error message was misleading me to think permissions when I really needed to check the hostname Postgres listens to.

EDIT add another note:

Psql on the client needs to have localhost specified or it will fail

```
psql  -h localhost
```

----------

