Don't know if it still works that way, but you don't need to guess the password, but generate a random string that have the same hash.
Noob question, but how do I check the login attempts from logs?
Thanks to great advice on this forum, I've just set this up.
So I keep Dropbear active but I disable root login as per below screenshot, correct?
But Luci https page , is still functional via root password.
Is it more difficult to brute force ssh and not Luci? (uHTTPd)
Or same difficulty ?
Is this the default setting? I remember in the past when I flashed a fresh openwrt the
Interface for Dropbear/SSH specified was something like
unspecified - would that by accident include the
ii is already protected, don't panic.
by default nothing (with very few exceptions) is accepted from WAN. so unless you manually expose a port you are protected from external attempts because network traffic is firewalled in owrt.
So I just figured I can disable uHTTPd via SSH. I rarely need use Luci after everything is setup.
I can enable uHTTPd manually via SSH when required.
And with SSH now only by 4096 bit KEY, I think that is good enough for security.
I'm new to OpenWRT . Thanks to the advice shared by this community
LuCI was never intended to be secure enough to leave open to the Internet. If you want to access LuCI remotely, always use a SSH tunnel or VPN.
A ssh tunnel is configured by adding -L 8080:localhost:80 to your CLI ssh login. Then leave the ssh session open and go to your web browser where
http://localhost:8080 (your localhost) is now linked to the remote LuCI (port 80 on that localhost).
Also note that https protects the client user from certain security risks, it does nothing to protect the server from a third party brute-force or other intrusion. So LuCI with https is not less risky than without.
I tried this but failed. Can you please help
In terminal from a laptop I did:
ssh firstname.lastname@example.org -L 8080:localhost:80
What is 'localhost' supposed to be there?
and then put in my passphrase for SSH key
But when I went to my browser, the old 192.168.1.1 went to Luci login screen (I didn't need 8080)
Appreciate any guidance
You need to reread what @mk24 wrote, and the tunnel doesn't stop the regular 192 access, unless you tell uhttpd to only bind to localhost.
Yes I've read a few times with no luck.
Can you help with how to do this please
As has been stated multiple times, unspecified listening interface does not actually mean that ssh is open on the WAN. The firewall is what is responsible for allowing or prohibiting access, and in the case of the WAN, it is prohibited unless the user adds a rule to allow ssh access from WAN.
Thanks for the tip to tell uhttpd to only bind to localhost. Done
But I had already done this: "Then leave the ssh session open and go to your web browser where
Nothing is coming up.
Should I disable https in Luci first or is that irrelevant? I had enabled redirecting http to https before
Yes, it still works that way. So it doesn't make sense to generate a password which has more bits than the hash. As far as I can count, the password in that screenshot has 39 characters, and a character is somewhere between 6 and 7 bits. So lets say this password is 256 bits.
To my surprise the hash in OpenWrt is md5 (unless that is somehow inherited from older installations, but I changed my password and it's still md5) which is 128 bits.
So that password isn't as hard to brute force as it seems. (Yet 128 bits is still enough to outlive the sun, assuming you are bruteforcing it)
Won't bite until restarted, I assume you've done it.
As for the ssh it should work, never actually done it on Linux, only Putty, but the syntax seems correct.
If you do telnet localhost 8080, does it open a session, or does it time out?
I also assume you're browsing (and telneting) from the same computer as your open ssh session ?
Yes same computer. I will do the telnet.
But do I leave it as "127.0.0.1.." as in that link you sent (for uci set uhttpd.main.listen_http='127.0.0.1:80')
Or change that to the IP address 192.168.1.1 of my OpenWrt RPi3?
Maybe that's where I stuffed up
It should be localhost/127.0.0.1.
Having a public web server online for many years already, fail2ban prevented any intrusion on port 22 and several others, i.e. 25 or 110. All relevant ports using password login, only, because I hate fiddling around with certs.