Show pagesourceOld revisionsBacklinksBack to top × Table of Contents SSH tunnel Sections Server Tunnels SSH tunnel providers See also SSH tunnel SSH tunnelling in OpenWrt can be done by using the sshtunnel package. Its uci configuration is located in /etc/config/sshtunnel. This file is responsible for defining ssh servers and tunnels. Sshtunnel depends on openssh-client, because the ssh client included by default on OpenWrt (dropbear) doesn't support most of the needed features. Sections A typical sshtunnel config file contains at least one server specifying the connection to a ssh server and one or more tunnelL, tunnelR or tunnelD defining Local, Remote or Dynamic tunnels. Server In most cases there will be only one server defined, but possibly several tunnels to this server. A minimal server declaration may look like the example below. config 'server' 'home' option 'user' 'jonh' option 'hostname' 'myhome.jonh.me' option 'port' '22' home will identify this server on the tunnels sections jonh specifies the username on the remote machine myhome.jonh.me is the hostname of a machine running a openssh ssh server. The possible options for server sections are listed in the table below. Name Type Required Default Description user string yes (none) remote host username. hostname string yes (none) remote host hostname. port integer yes (none) Port to connect to on the remote host. Note that this seems to be REQUIRED although being optional in older releases. IdentityFile string no (openssh ssh_config default) Specifies a file from which the user's RSA, ed25519 or ECDSA authentication identity is read. The default is /root/.ssh/id_rsa, /root/.ssh/id_ed25519 and /root/.ssh/id_ecdsa. retrydelay integer no 10 Delay after a connection failure before trying to reconnect. CheckHostIP string no (openssh ssh_config default) If this flag is set to yes, ssh(1) will additionally check the host IP address in the known_hosts file. This allows ssh to detect if a host key changed due to DNS spoofing. If the option is set to no, the check will not be executed. The default is yes. Compression string no (openssh ssh_config default) Specifies whether to use compression. The argument must be yes or no. The default is no. CompressionLevel string no (openssh ssh_config default) Specifies the compression level to use if compression is enabled. The argument must be an integer from 1 (fast) to 9 (slow, best). The default level is 6, which is good for most applications. The meaning of the values is the same as in gzip(1). Note that this option applies to protocol version 1 only. LogLevel string no (openssh ssh_config default) Gives the verbosity level that is used when logging messages from ssh(1). The possible values are: QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3. The default is INFO. DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify higher levels of verbose output. ServerAliveCountMax string no (openssh ssh_config default) Sets the number of server alive messages (see below) which may be sent without ssh(1) receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session. It is important to note that the use of server alive messages is very different from TCPKeepAlive (below). The server alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable. The server alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive. The default value is 3. If, for example, ServerAliveInterval (see below) is set to 15 and ServerAliveCountMax is left at the default, if the server becomes unresponsive, ssh will disconnect after approximately 45 seconds. This option applies to protocol version 2 only. ServerAliveInterval string no (openssh ssh_config default) Sets a timeout interval in seconds after which if no data has been received from the server, ssh(1) will send a message through the encrypted channel to request a response from the server. The default is 0, indicating that these messages will not be sent to the server. This option applies to protocol version 2 only. StrictHostKeyChecking string no (openssh ssh_config default) If this flag is set to “yes”, ssh(1) will never automatically add host keys to the ~/.ssh/known_hosts file, and refuses to connect to hosts whose host key has changed. This provides maximum protection against trojan horse attacks, though it can be annoying when the /usr/local/etc/ssh_known_hosts file is poorly maintained or when connections to new hosts are frequently made. This option forces the user to manually add all new hosts. If this flag is set to “no”, ssh will automatically add new host keys to the user known hosts files. If this flag is set to “ask”, new host keys will be added to the user known host files only after the user has confirmed that is what they really want to do, and ssh will refuse to connect to hosts whose host key has changed. The host keys of known hosts will be verified automatically in all cases. The argument must be “yes”, “no”, or “ask”. The default is “ask”. TCPKeepAlive string no (openssh ssh_config default) Specifies whether the system should send TCP keepalive messages to the other side. If they are sent, death of the connection or crash of one of the machines will be properly noticed. However, this means that connections will die if the route is down temporarily, and some people find it annoying. The default is “yes” (to send TCP keepalive messages), and the client will notice if the network goes down or the remote host dies. This is important in scripts, and many users want it too. To disable TCP keepalive messages, the value should be set to “no”. VerifyHostKeyDNS string no (openssh ssh_config default) Specifies whether to verify the remote key using DNS and SSHFP resource records. If this option is set to “yes”, the client will implicitly trust keys that match a secure fingerprint from DNS. Insecure fingerprints will be handled as if this option was set to “ask”. If this option is set to “ask”, information on fingerprint match will be displayed, but the user will still need to confirm new host keys according to the StrictHostKeyChecking option. The argument must be “yes”, “no”, or “ask”. The default is “no”. Note that this option applies to protocol version 2 only. Tunnels A complete sshtunnel configuration contains at least one tunnelR, tunnelL, tunnelD or tunnelW sections, which will make use of a server. tunnelR A example for a tunnelR declaration is given below: config tunnelR local_ssh option server 'home' option remoteaddress '*' option remoteport '2222' option localaddress '127.0.0.1' option localport '22' * means to accept a connection from any interface on the Server side Specifying a remote bind_address will only succeed if the server's GatewayPorts option is enabled (see sshd_config(5)) 2222 is the TCP port to bind on the Server side 127.0.0.1 is the OpenWrt side address to where the remote connection will be forwarded 22 is the OpenWrt side TCP port where to the remote connection will be forwarded The equivalent ssh(1) command would be ssh -R *:2222:127.0.0.1:22 jonh@myhome.jonh.me The possible options for tunnelR sections are listed in the table below: Name Type Required Default Description server string yes (none) Specifies the used server, must refer to one of the defined server sections remoteaddress string no * Server side address remoteport integer yes (none) Server side TCP port localaddress string yes (none) OpenWrt side address localport integer yes (none) OpenWrt side TCP port tunnelL For a tunnelL the declaration is similar: config tunnelL server_http option server 'home' option remoteaddress '127.0.0.1' option remoteport '8080' option localaddress '*' option localport '80' 127.0.0.1 is the Server side address to where the connection will be forwarded 8080 is the Server side TCP port to where the local connection will be forwarded * means to accept a connection from any interface on the OpenWrt side 80 is the local TCP port to bind on the OpenWrt side The equivalent ssh(1) command would be ssh -L *:80:127.0.0.1:8080 jonh@myhome.jonh.me The possible options for tunnelL sections are listed in the table below: Name Type Required Default Description server string yes (none) Specifies the used server, must refer to one of the defined server sections remoteaddress string yes (none) Server side address remoteport integer yes (none) Server side TCP port localaddress string no * OpenWrt side address localport integer yes (none) OpenWrt side TCP port tunnelD A tunnelD declaration will create a SOCKS proxy accessible on the defined port: config tunnelD proxy option server 'home' option localaddress '*' option localport '1080' * means to accept a connection from any interface on the OpenWrt side 1080 is the local TCP port to bind on the OpenWrt side The equivalent ssh(1) command would be ssh -D *:1080 jonh@myhome.jonh.me The possible options for tunnelD sections are listed in the table below: Name Type Required Default Description server string yes (none) Specifies the used server, must refer to one of the defined server sections localaddress string no * OpenWrt side address localport integer yes (none) OpenWrt side TCP port tunnelW A tunnelW declaration will TUN/TAP devices on client and server to establish a VPN tunnel between them. config tunnelW vpn option server 'home' option vpntype 'point-to-point' option localdev 'any' option remotedev 'any' The equivalent ssh(1) command would be ssh -o Tunnel=point-to-point -w any:any jonh@myhome.jonh.me The possible options for tunnelW sections are listed in the table below: Name Type Required Default Description server string yes (none) Specifies the used server, must refer to one of the defined server sections vpntype string no point-to-point point-to-point or ethernet remotedev string yes any tun device numerical ID or the keyword any, which uses the next available tunnel device localdev string yes any remote device ID See Arch Wiki VPN over SSH SSH tunnel providers srv.us works with empty RemoteAddress or set to '*'. You can also set a custom domain as a number 1, 2 etc. localhost.run works with empty RemoteAddress or set to '*' but the generated domain will be rotated and changed on next restart. You need a custom domain (paid feature). remote.moe works only if a custom domain but this needs for some manual configuration. See other options in the Awesome tunneling: SSH services See also Video: Setup SSH tunnel on router OpenWrt - Reverse SSH tunnel in Polish OpenWrt SSH tunnel LUCI app sshtunnel WIP howto: SOCKS Proxy SSH Tunnels on OpenWRT howto: OpenWrt SSH Tunneling sshtunnel SystemD port of the sshtunnel to other SystemD based Linux distros (Ubuntu, Debian etc). This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.OKMore information about cookies Last modified: 2023/07/06 09:26by stokito