View previous topic :: View next topic |
Author |
Message |
turtles Veteran
Joined: 31 Dec 2004 Posts: 1658
|
Posted: Tue Jul 16, 2013 1:20 am Post subject: Does ssh tunnel require tun/tap driver in kernel? [solved] |
|
|
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 |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21639
|
Posted: Tue Jul 16, 2013 1:28 am Post subject: |
|
|
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 |
|
|
turtles Veteran
Joined: 31 Dec 2004 Posts: 1658
|
Posted: Tue Jul 16, 2013 4:17 am Post subject: |
|
|
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 |
|
|
imaginasys Tux's lil' helper
Joined: 26 Dec 2009 Posts: 83 Location: Québec
|
Posted: Tue Jul 16, 2013 5:10 am Post subject: |
|
|
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 |
|
Back to top |
|
|
turtles Veteran
Joined: 31 Dec 2004 Posts: 1658
|
Posted: Tue Jul 16, 2013 6:20 am Post subject: |
|
|
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:
_________________ Donate to Gentoo |
|
Back to top |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Tue Jul 16, 2013 8:50 am Post subject: |
|
|
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 |
|
|
turtles Veteran
Joined: 31 Dec 2004 Posts: 1658
|
Posted: Tue Jul 16, 2013 4:17 pm Post subject: |
|
|
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 |
|
|
mike155 Advocate
Joined: 17 Sep 2010 Posts: 4438 Location: Frankfurt, Germany
|
Posted: Tue Jul 16, 2013 6:08 pm Post subject: |
|
|
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 |
|
|
turtles Veteran
Joined: 31 Dec 2004 Posts: 1658
|
Posted: Tue Jul 16, 2013 9:58 pm Post subject: |
|
|
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
_________________ Donate to Gentoo |
|
Back to top |
|
|
|
|
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
|
|