Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Does ssh tunnel require tun/tap driver in kernel? [solved]
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
turtles
Veteran
Veteran


Joined: 31 Dec 2004
Posts: 1655

PostPosted: Tue Jul 16, 2013 1:20 am    Post subject: Does ssh tunnel require tun/tap driver in kernel? [solved] Reply with quote

Does a ssh tunnel require tun/tap driver in kernel?
Thanks
(Trying to set up a non root ssh tunnel)
_________________
Donate to Gentoo


Last edited by turtles on Tue Jul 16, 2013 10:00 pm; edited 1 time in total
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 21595

PostPosted: Tue Jul 16, 2013 1:28 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
turtles
Veteran
Veteran


Joined: 31 Dec 2004
Posts: 1655

PostPosted: Tue Jul 16, 2013 4:17 am    Post subject: Reply with quote

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:
Code:
ssh -vvL 3333:XXXXXXXXX.com:5432 XXXXXXXXXX.com


Code:

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:
Code:
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 :) thanks
_________________
Donate to Gentoo
Back to top
View user's profile Send private message
imaginasys
Tux's lil' helper
Tux's lil' helper


Joined: 26 Dec 2009
Posts: 83
Location: Québec

PostPosted: Tue Jul 16, 2013 5:10 am    Post subject: Reply with quote

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 :mrgreen:
Back to top
View user's profile Send private message
turtles
Veteran
Veteran


Joined: 31 Dec 2004
Posts: 1655

PostPosted: Tue Jul 16, 2013 6:20 am    Post subject: Reply with quote

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
Code:
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:

Code:
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:
Code:
   
Tunnel yes
#   TunnelDevice any:any


and on server:
Code:
PermitTunnel yes

_________________
Donate to Gentoo
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Tue Jul 16, 2013 8:50 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
turtles
Veteran
Veteran


Joined: 31 Dec 2004
Posts: 1655

PostPosted: Tue Jul 16, 2013 4:17 pm    Post subject: Reply with quote

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
on the configuration of your PostgreSQL database server.


AAH thanks bug_report ! That was it. The command I needed was
Code:
ssh -vL 3333:localhost:5432 XXXXXXXXXX.com


Now I get this log:
Code:
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?
_________________
Donate to Gentoo
Back to top
View user's profile Send private message
mike155
Advocate
Advocate


Joined: 17 Sep 2010
Posts: 4438
Location: Frankfurt, Germany

PostPosted: Tue Jul 16, 2013 6:08 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
turtles
Veteran
Veteran


Joined: 31 Dec 2004
Posts: 1655

PostPosted: Tue Jul 16, 2013 9:58 pm    Post subject: Reply with quote

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:
Code:
 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
Code:
psql  -h localhost

_________________
Donate to Gentoo
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum