nvram set remote_management=1
nvram set http_wanport=8080
nvram set httpsd_enable=1
nvram set https_enable=1
nvram set remote_mgt_https=1
nvram commit
reboot
But I still agree with bkmo. You should try using search more often.
P.S. - I have just added these instructions to the Wiki here -> Web Interface - Regaining Access. If anyone shall ask this question again in the future, you now have an easier point of reference.
You could also setup tunneling in your SSH client and not enable remote https management. For example, in Putty you could add:
Souce Port: 9000
Destination: localhost:80
After making the SSH connection, fire up your browser and connect to http://localhost:9000/
This would tunnel the connection through SSH. In the above example, the source port (9000) is the port you use on your local client machine to connect to the destination (router on port 80).
That's a very good point! It's a secure solution, while also having benefit of saving valuable router resources (no need for extra HTTPS service running in the background). Just encrypt the HTTP traffic through SSH tunnel.
I use the SSH tunnel a lot so I don't have to open many ports to the world, and like you said the entire connection is encrypted. It works well for RDP connections as well. I also like the ability to use the router as a proxy server through the SSH tunnel. Most networks allow port 22 through.
nvram set remote_management=1
nvram set http_wanport=8080
nvram set httpsd_enable=1
nvram set https_enable=1
nvram set remote_mgt_https=1
nvram commit
reboot
But I still agree with bkmo. You should try using search more often.
P.S. - I have just added these instructions to the Wiki here -> Web Interface - Regaining Access. If anyone shall ask this question again in the future, you now have an easier point of reference.
Thanks. I had found bits and pieces of how to handle this locally, but was having trouble getting everything together for enabling the remote connection. The help is very appreciated.
bige wrote:
You could also setup tunneling in your SSH client and not enable remote https management. For example, in Putty you could add:
Souce Port: 9000
Destination: localhost:80
After making the SSH connection, fire up your browser and connect to http://localhost:9000/
This would tunnel the connection through SSH. In the above example, the source port (9000) is the port you use on your local client machine to connect to the destination (router on port 80).
I hope this helps.
That helps quite a bit, actually. I actually needed SSH-HTTP tunneling for another aspect of the project I'm working on, so this actually takes care of how to set that up as well. Thanks.
I use the SSH tunnel a lot so I don't have to open many ports to the world, and like you said the entire connection is encrypted. It works well for RDP connections as well. I also like the ability to use the router as a proxy server through the SSH tunnel. Most networks allow port 22 through.
i will be much happier if i could see this tutorial somewhere to configure my router!
really most secure than open ports to the world!
Why? For convenience I once opened the standard SSH port to the world and my log revealed that people running scripts tried gaining access. I assume they look at random systems for standard ports, known exploits, common usernames (root, admin, user, system) and a list of commonly used passwords. Although they never manage to gain access, I just do not want them to know about my SSH port. After switching to a non-standard port, my log didn't show any more attempts, because the scripts do not do a time-consuming port scan.
If you don't want to do change the port or the username, using a very(!) strong password may be sufficient.
[off topic] SSH Security Hints
DD-WRT's CLI has two users: root and reboot. They both have the same password. Logging in as reboot is just a fast way to reboot the router. You might also want to rename this user.
I myself rely on the security measures mentioned above, but please do not underestimate the potential hardware damage a malicious hacker can do. Once logged in, he could set the TX power and the overclock frequency to the maximum. He could also more subtly damage your non-volatile memory by running a script that does millions of writes to NVRAM or JFFS.
When connecting to a DD-WRT system, it reveals the OS before having to enter a password. A malicious hacker seeing you are using DD-WRT might do some extra effort to hack his way in, because he might want to damage your hardware if he knows about the potential hardware exploits I described above. You might change the file /tmp/loginprompt.
At this moment I'm using a build which doesn't have this feature, but I saw one having a setting called 'limit SSH access'. I assume it blocks access to systems that repeatedly use wrong passwords. That's seems OK to me, but I couldn't set this to 'on', because it was set to 'off' after applying settings. (I haven't searched for more information about this feature yet, so I may have done something wrong.)
Most people here already know this. Never use Telnet, because any data (even your password) is sent unencrypted.
Joined: 16 Apr 2018 Posts: 108 Location: Milwaukee, WI
Posted: Tue Mar 12, 2024 21:48 Post subject: Disabling Local Access to Web Interface when not using it
soulstace wrote:
also,
nvram set remote_management=1
nvram set http_wanport=8080
nvram set httpsd_enable=1
nvram set https_enable=1
nvram set remote_mgt_https=1
nvram commit
reboot
But I still agree with bkmo. You should try using search more often.
P.S. - I have just added these instructions to the Wiki here -> Web Interface - Regaining Access. If anyone shall ask this question again in the future, you now have an easier point of reference.
Hey, I'm trying to disable my DD-WRT web interface completely from SSH when I'm not using the web interface of DD-Dwrt. Open-WRT has a command to enable and disable Luci (web interface). I'm wondering if these commands you posted are going to do the same thing? I just want to ssh into my router, and enable the web interface locally only when I use it to make changes, and then disable it with ssh after I'm done using it and making changes.
What commands that you have listed will do this? I'm not sure which ones do which for disabling and re-enabling. Let me know. Thanks _________________ DanRanRocks - Tech Tutorials by Dan Ran
That post you quoted is 16 years old. Things have change a lot since then. It is not recommended to enable http(s) access on your WAN port at all (or ssh for that matter). For remote access, use Wireguard. _________________ Linksys EA8500 (Internet Gateway, AP/VAP) - DD-WRT r53562
Features in use: WDS-AP, Multiple VLANs, Samba, WireGuard, Entware: mqtt, mlocate
Wireless 5ghz only
Netgear R7800 (WDS-AP, WAP, VAP) - DD-WRT r55779
Features in use: multiple VLANs over single trunk port
Linksys EA8500 WDS Station x2 - DD-WRT r55799
Netgear R6400v2 WAP, VAP 2.4ghz only w/VLANs over single trunk port. DD-WRT r55779
OSes: Fedora 38, 9 RPis (2,3,4,5), 20 ESP8266s: Straight from Amiga to Linux in '94, never having owned a Windows PC.
Joined: 26 Mar 2013 Posts: 1858 Location: Hung Hom, Hong Kong
Posted: Wed Mar 13, 2024 10:40 Post subject:
Two commands setpasswd and setuserpassword might interest you. They alter the password and/or username of the WEBUI. The WEBUI password is also the password of root in /tmp/etc/passwd.
You can also move the WEBUI port using 'nvram http_lanport=9999' if you wanna use port 80 as the port for Lighttpd the regular web server. You might wanna set http_wanport to an impossible value!
BTW, you can launch WEBUI directly using command 'httpd -n -p 9999' (-p is port number) when in a shell, ignoring WEBUI-related nvram values. Then WEBUI would not stay alive all the time without your attention, only in an SSH session. And before you logout, you might wanna stop WEBUI by 'killall httpd' or 'service httpd stop'!
One thing: Better set http_enable=1 BEFORE you flash a new DD-WRT build just in case the upgrade went wrong. _________________ Router: Asus RT-N18U (rev. A1)
Drink, Blink, Stretch! Live long and prosper! May the Force and farces be with you!