Openwrt ssh from wan

Secure your router’s access

There are some possibilities to grant access to the router (or to any PC/Server):

If you ask for username/password, an attacker has to guess the combination. If you use an unencrypted connection, he could eavesdrop on you and obtain them.

If you use an encrypted connection, any eavesdropper would have to decrypt the packets first. This is always possible. How long it takes to decrypt the content, depends on the algorithm and key length you used.

Also, as long as an attacker has network access to the console, he can always run a brute-force attack to find out username and password. He does not have to do that himself: he can let his computer(s) do the guessing. To render this option improbable or even impossible you can:

System hardening

If you have an external disk you may want to encrypt it.

Network hardening

See detailed instructions at: Fwknop

Create a non-privileged user in OpenWrt

Example that adds a user called nicolaus:

Or add the user by hand (Take care that uid/gid (e.g.=1000) are not already in use!)

However, you can’t ssh to this user yet. To enable ssh access, you should make a password for that user, create his home folder and most importantly indicate the shell of that user:

Allow temporary privileged access using sudo

First, you should install sudo :

Additionally, you must allow your desired user by manipulating ‘/etc/sudoers ‘ by tool visudo . Now you can follow ONE of the methods below to choose how the user should be able to run commands as root :

Method 1: ‘sudo’ing by any user with root password (more secure)

In this method any user can temporarily run commands as root only if he knows the root password. This way when the user runs a command with sudo he should enter root’s password instead of his password.

For enabling this method you should open the file ‘/etc/sudoers ‘ by entering the command

Then uncomment the 2 lines below in that file and then save

This method is more secure because you don’t need to protect both root and privileged (sudoer) users to keep the whole system safe.

Method 2: ‘sudo’ing with the user’s password

In this method, after logging in by the desired user, when you enter sudo you should enter the user’s password again. The end result is similar to how you use sudo in Ubuntu or other popular Linux disros, but this method doesn’t utilize group ‘sudo’ for this purpose.

For enabling this method you should also enter the command

And then add a line allowing your user, under comment “## User privilege specification”:

Method 3: ‘sudo’ing with the user’s password if he is member of group ‘sudo’ (needs installing some packages)

This method is very similar to Method 2, except that it allows any member of group ‘sudo’ to use sudo with their own password. This method is exactly the same one used in Ubuntu and other popular Linux distros to allow ‘sudo ‘ access for a user.

For activating this method first you should allow group ‘sudo’ to use command sudo by entering

And then uncomment the line below:

Second you should create group ‘sudo’. You can do it by manually editing ‘/etc/group ‘ but it’s more standard to install and use tools for this purpose:

And finally add your current user to the group ‘sudo’. You can directly append your user to ‘/etc/group ‘ but again it’s better to use usermod :

This method is more convenient because you can simply allow sudo access for any user you want, just by usermod -a -G sudo but takes more space (for installing new packages) than method 2 which may be more suitable for systems with very limited space.

If you are using ppp in the default configuration with username and password in /etc/config/network , then the unprivileged user can read it from pppd’s command line (with e.g. ps w ). To prevent that, you can add “ user ” to /etc/ppp/options and “ *

” to /etc/ppp/-secrets and then remove the username / password options from uci configuration.

Of course /etc/ppp/-secrets should not be world readable:

Can mandatory client certificate checking be set up with uhttpd? → not possible with uhttpd

• Last modified: 2020/10/03 20:58
• by vgaetera

Self-registration in the wiki has been disabled.
If you want to contribute to the OpenWrt wiki, please post HERE in the forum or ask on IRC for access.

Except where otherwise noted, content on this wiki is licensed under the following license:
CC Attribution-Share Alike 4.0 International

Источник

SSH access for newcomers

The first time you ssh into your router, you will probably see a warning about the RSA key fingerprint. If you are certain this is the address of your OpenWrt device, simply type yes and press Return. Then enter the password you have given to your router, or press Return if this is the initial setup. Here is an example session:

To end your ssh session to your router, type exit and press Return.

The remainder of this page describes several terminal emulators that Windows, Linux, or macOS can use to access your OpenWrt device.

Windows terminal emulators

Windows Terminal or the legacy PowerShell, Command Prompt, ConHost, or WSL Bash choices are available. Third party programs such as PuTTY, MinGW (installed with Git), Cmder, SmarTTY, and WinSCP are also terminal emulators that can provide SSH into an OpenWrt router.

Windows 10/11 built-in terminals

If you directly launch cmd.exe , powershell.exe or wsl.exe the legacy ConHost terminal will open. Otherwise, you can install the modern Windows Terminal from the MS store and select any of these shells from there.

PowerShell

Windows Subsystem for Linux (WSL)

The Windows Subsystem for Linux is a convenient way to run a Linux environment of your choice including most,command-line tools, utilities, and applications directly on Windows. For detailed steps of how to install WSL on Windows 10, refer to Microsoft’s documentation: https://docs.microsoft.com/en-us/windows/wsl/install-win10

PuTTY

PuTTY gives you command-line access to OpenWrt.

Setting up key-based authentication.

WinSCP

WinSCP allows you to browse the OpenWrt file system in Windows Exlorer like GUI -style.

Editing OpenWrt config files with WinSCP’s integrated GUI editor.

Cmder

Cmder for Windows is an open-source terminal emulator that runs on Windows. It is free to use and provides an easy “command line shell” that allows you to ssh into OpenWrt. Its attractive fonts and color scheme are easy on the eyes. The Full distribution is preferred (over the mini distribution), since it provides a bash emulation, with a Unix-y suite of commands.

SmarTTY

SmarTTY gives you command line access to OpenWrt and allows you to open/edit/download/upload files in OpenWrt, and is overall more modern and user-friendly than PuTTY (another tool detailed below).

Linux terminal emulators

All Linux distributions provide a command-line ssh client as part of the default installation.

Midnight Commander

Midnight Commander is Norton Commander like file manager that works on Linux and macOS. You can access remote files on OpenWrt via mc:

Internally it works over scp like protocol FISH so it not needs for installed SFTP server.

macOS terminal emulators

On macOS (formerly Mac OSX) any terminal emulator will allow you to ssh.

To ssh into your OpenWrt router at 192.168.1.1, type ssh root@192.168.1.1 , then press Return.

ChromeOS terminal emulator

• Last modified: 2022/08/05 15:30
• by palebloodsky

Self-registration in the wiki has been disabled.
If you want to contribute to the OpenWrt wiki, please post HERE in the forum or ask on IRC for access.

Except where otherwise noted, content on this wiki is licensed under the following license:
CC Attribution-Share Alike 4.0 International

Источник

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. There are two versions:

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.

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.
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.
IdentityFile	string	no	(openssh ssh_config default)	Specifies a file from which the user’s RSA or DSA authentication identity is read. The default is

/.ssh/identity for protocol version 1, and

/.ssh/id_dsa for protocol version 2. Additionally, any identities represented by the authentication agent will be used for authentication. ssh(1) will try to load certificate information from the filename obtained by appending -cert.pub to the path of a specified IdentityFile. The file name may use the tilde syntax to refer to a user’s home directory or one of the following escape characters: ‘%d’ (local user’s home directory), ‘%u’ (local user name), ‘%l’ (local host name), ‘%h’ (remote host name) or ‘%r’ (remote user name). 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 or tunnelD sections, which will make use of a server.

tunnelR

A example for a tunnelR declaration is given below:

Specifying a remote bind_address will only succeed if the server’s GatewayPorts option is enabled (see sshd_config(5))

The equivalent ssh(1) command would be “ssh -R *:14000: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:

The equivalent ssh(1) command would be “ssh -L *:4422:127.0.0.1:80 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:

The equivalent ssh(1) command would be “ssh -D *:12345 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

• Last modified: 2022/10/25 21:27
• by cpswan

Self-registration in the wiki has been disabled.
If you want to contribute to the OpenWrt wiki, please post HERE in the forum or ask on IRC for access.

Except where otherwise noted, content on this wiki is licensed under the following license:
CC Attribution-Share Alike 4.0 International

Источник