Remote Access to OpenWrt (first ssh, then webinterface)

Installing and Using OpenWrt
1

I can't get this to work. I want to be able to ssh into my router from an external IP securely. Next step is accessing the web interface.

Port-forwarding config:

config redirect
        option enabled '1'
        option target 'DNAT'
        option src 'wan'
        option dest 'lan'
        option proto 'tcp'
        option dest_ip '192.168.1.1'
        option dest_port '22'
        option name 'Remote Access (WAN to SSH LAN)'
        option src_dport '17000'

Command I'm using in my terminal:

ssh -L17000:192.168.1.1:22 root@myexternalip

But I keep getting connection refused. What am I doing wrong? I want to get this to work before changing the default ssh port and opening up another dropbear instance to make this more secure. I can't find a guide anywhere that dumbs this down.

2

You do not need to set up forwarding on OpenWrt to handle this, as I understand your use case

remote-machine $ ssh -L8080:localhost:80 you@your.router

sets up the port forwarding needed from your router to "remote-machine". You then would access the GUI through your browser on remote-machine at

http://localhost:8080/

(substituting 443 with HTTP-S and 8080 is "any" port of your choice)

4

Thanks for the quick reply. That's odd, it goes against everything I've read. When I tried your solution I got:

ssh -L8080:localhost:80 root@myip.net
ssh: connect to host myip.net port 22: Connection refused
5

Have you opened your firewall to allow incoming connections to port 22 on your WAN?

6

Maybe incorrectly?

12%20AM

Wait, I fixed it.

00%20AM

But this doesn't seem like a secure solution?

1 Like
7

192.168.1.1 is your LAN address, not your outside IP.

Update on your update:

ssh provides a reasonable level of security. I'm not a big fan of "root" logins over ssh and personally use OpenSSH, configure a non-privileged user, and sudo, but many find that the security of dropbear and a root login is sufficient for their needs. Some consider that changing the port provides additional "security", but I personally find those arguments unfulfilling.

2 Likes
8

Fixed that, however https://localhost:8080 does not work to access the WebGUI

Firefox says "The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem."

I do have uhttpd setup to access the webGUI securely.

9

What you are now seeing is the "problem" with self-signed certificates. It is not an OpenWrt issue. You could resolve this by one of the following:

  • "Accept" the certificate in your browser, once you've verified that it is the one you expect from your OpenWrt server
  • Go through the rigors of creating your own "CA", then installing the "trusted" certificate of that CA in each of the browsers that you wish to access
  • Configure uhttpd so that it only accepts insecure (HTTP) connections on localhost (127.0.0.1) and forward port 80 (encryption will be provided by the ssh tunnel and by binding only to localhost, insecure access isn't exposed to your LAN hosts)

Edit: The "best" solution, perhaps, is to learn how to do what you need to through the command line, coupled with creating a non-privileged login and sudo. Regrettably, running LuCI in a non-privileged mode is a rather complex task, one that I long ago gave up on.

1 Like
10
  1. Unfortunately I cannot accept the certificate in my browser (although I already did that and saved the certificate when I connected via LAN) It's not even giving me the option.

57%20AM
57%20AM2270×1204 145 KB

Edit: adding https://localhost to Firefox's about:config security.tls.insecure_fallback_hosts line did not solve the problem as suggested here: https://support.mozilla.org/en-US/questions/1058856

  1. Do you know of a guide for this option?

  2. If I configure it this way wouldn't this also apply when I'm connected on LAN? I'd rather be connected securely on LAN, even though yes, I know all the other hosts who could be snooping traffic are local.

11

Indeed, I use ports from the ephemeral range (NAT ports 32768-60999). I also use softflowd to monitor traffic...and a firewall drop rule to only allow x SYNs on the port in x minutes from the SRC IP.

I use a downstream SSH server with a non-root login. This probally won't help the OP, unless he has another OpenWrt laying around (then the device would only be used for SSH)

LAN clients cannot snoop traffic between your SSH connection and the router, as the traffic never leaves the device.

12

Not ignoring you, I just haven't used Firefox for years. I re-confirmed that I can connect to my Cisco switches that use self-signed certificates under Chrome:

image

1 Like
13

In my version of Firefox, I have an advanced button that allows me to temporally or permanently accept the certificate.

14

Hmm, in both Firefox 61.0.2 and Safari 11.1.2 I cannot accept any of the certificates. It says Safari can't establish a secure connection to the server.

Do I need to change my uHTTPd settings? Right now I have the "Ignore private IPs on public interface" box checked, is that preventing it from sending the certificates?

I also have dropbear instance running in the default settings. Is dropbear different from uHTTPd? I'm a little confused between the two.

15
16

Thanks, but unfortunately it won't even load from there, telling me this is a server settings issue

46%20PM

What are your hTTPd settings? Here are mine.

22%20PM

17

You do not need https through a SSH tunnel. It is safe to use regular http since ssh will encrypt everything.

The http server on the router must be open only to the internal network. Your -L tunnel makes it external, for the SSH user only.

1 Like
18

Yes, dropbear is the default SSH server installed with OpenWrt and uhttpd is the default web server installed with OpenWrt.

Certificates are used for two reasons:

There is not the same "issue" with ssh as it assumes that you can check the validity of the certificate the first time you see it. Generally your ssh client will show you a certificate "fingerprint" and ask if you trust it. Admittedly, most people just say "Y", but the option is there for "manual" verification (as well as some complex ways to establish certificate trust that most individuals don't configure).

With a web browser, things are a little different. They are designed for non-expert users and try to protect them from malicious activity. In a web browser, the authentication part is just as important as the encryption part. This is generally handled by a chain of trust -- there are several dozen "generally trusted" authorities that issue certificates, or entrust others and "sign" for their trustworthiness. Their certificates can be used to confirm that a different certificate is "trustworthy" when it is presented. These "top-level" certificates are generally delivered with the browser, and/or through a "CA bundle" or the like from some other trusted source.

In a typical HTTP-S connection, the certificate of the server is sent. The browser compares the "name" of the server on the certificate with that of the URL requested. Unless things are really misconfigured, they match, even with "self-signed" certificates. Then it checks to see if the signature on that certificate is "trusted" against its CA store. If it matches properly, the browser sets up the connection and starts talking over an encrypted channel. These days, there is an indication in the UI that this match has occurred, like image

If it does not match a known, trusted CA, then it can still be used for encryption, but it requires explicit confirmation on the user's part in current browsers, since there is no way for the browser to confirm that you're talking with my-bank.example.com or the like. A different message is shown in most browsers to say "well, your browser doesn't really trust this connection" image

1 Like
19

It seems like you're accessing the HTTP service using the HTTPS protocol. Assuming you are using luci-ssl and HTTPS, your ssh forwarding command should be something like:

ssh -L8443:localhost:443 root@myip.net

and then access via your browser using (as @jeff suggested):

http://localhost:8443/

Using a non-standard WAN listening port and enforcing certificate-based authentication for SSH should be considered a minimum. It's also worthwhile to NOT permanently open the firewall port. Instead, for example, one can configure Single Packet Authorization using the OpenWrt fwknopd service, which can temporarily open your SSH port in a secure manner.

20

Thanks for that. I fixed it by unchecking "redirect all HTTP to HTTPS" option in uHTTPd and connected to http://localhost:8080 successfully! You guys are awesome. I hope to contribute to the wiki to write a good guide for newbies like me.

Anyway, we're almost there. Now I have a problem connecting to my transmission RPC port at 9091. It can't connect through the browser. Admittedly, I can run transmission through the CLI via my ssh tunnel, but I don't really know how to load torrents without going into the web interface.

When I tried tunneling through port 9091 instead of 8080 the website just redirected me to the LuCI webserver and I couldn't access transmission? I'm assuming this is because you can't have the same port run both applications over the browser. Does anyone have any ideas?

21

Just as an alternative suggestion, while I've used ssh tunnels in the past, I strongly recommend a full fledged VPN solution (e.g. strongswan, wireguard, OpenVPN, ...) these days - it's just much more convenient.

3 Likes