-
This has got to be written down somewhere already, and I apologize for not being able to find it.
On pfSense 2.0b4 there is a nifty new user manager. I've discovered that this also implies that when one ssh's into the router; one does not have root permissions.
"admin" is listed in group wheel, but newly created "admins" are not. Is that a deliberate decision, or an oversight? I can use Diagnostics –> Edit File to add additional users to that group with no trouble.
I disabled "admin" since it is way too guessable (at least one of our installations was hacked thru dictionary attacks) and avoided "root" for the same reason. Is it still the case (in pfSense 2.0) that changes to admin's password are mirrored into user root?
Thanks.
-
http://www.grc.com/passwords, no need to disable anything if you have a good enough passwords for admin/root/whatever accounts.
Also consider restricting access to the webgui to only a handful of known trusted addresses, opening it wide open is just asking for trouble.
-
Actually, anyone that has shell access to a 2.0 box should be considered to have root access. It's not meant to be a general purpose restricted user platform. It's a firewall, and anyone with any kind of access to the shell should be considered root. Sure, they don't all have root access, but before release we are probably going to drop sudo in and give any shell user access to sudo.
You should never ever leave ssh exposed to the world on the default port unless you are using key-only auth. I still don't trust it even on an alternate port, I have mine heavily restricted by IP, instead preferring to access it via VPN.
There is no excuse for having a weak password on a box like that, especially with exposed services.
-
@kpa:
http://www.grc.com/passwords, no need to disable anything if you have a good enough passwords for admin/root/whatever accounts.
You're right. But when one considers the total amount of unpredictability, changing the name from the obvious "admin" allows you to maintain the same total amount of indeterminacy with a shorter password. There's no way I'm capable of memorizing 63 char for dozens of boxen.
@kpa:
Also consider restricting access to the webgui to only a handful of known trusted addresses, opening it wide open is just asking for trouble.
Yup, we do that too.
-
You're right. But when one considers the total amount of unpredictability, changing the name from the obvious "admin" allows you to maintain the same total amount of indeterminacy with a shorter password. There's no way I'm capable of memorizing 63 char for dozens of boxen.
"root" is a thousand times more obvious to ssh brute force scanners than "admin".
-
Actually, anyone that has shell access to a 2.0 box should be considered to have root access. It's not meant to be a general purpose restricted user platform. It's a firewall, and anyone with any kind of access to the shell should be considered root. Sure, they don't all have root access, but before release we are probably going to drop sudo in and give any shell user access to sudo.
You should never ever leave ssh exposed to the world on the default port unless you are using key-only auth. I still don't trust it even on an alternate port, I have mine heavily restricted by IP, instead preferring to access it via VPN.
There is no excuse for having a weak password on a box like that, especially with exposed services.
Nope. ssh is limited to just a few blocks. It's key only. We're paranoid too. The point about supplying sudo is interesting. But I'm still wondering about root's password?
Is is tied to sync with the password assigned to "admin?"
Will root login be disabled in production? Perhaps, with sudo, that would be pointless?
Thanks.
-
You're right. But when one considers the total amount of unpredictability, changing the name from the obvious "admin" allows you to maintain the same total amount of indeterminacy with a shorter password. There's no way I'm capable of memorizing 63 char for dozens of boxen.
"root" is a thousand times more obvious to ssh brute force scanners than "admin".
Well, yah. Which is why I'm trying to avoid both.
-
If you are using key-only auth, no amount of brute forcing will matter.
root and admin are tied togeher. Their passwords are linked.
root is needed because the admin account's shell is locked to the menu, and root is not, so it is used for scp and other ssh features that will not work with the admin user.
-
Sorry, I meant using a short snippets from that page as passwords, not the full 63 character long passwords. I use 8 character passwords that I hand pick from the "The 63 alphanumeric-only character subset" so that the passwords are still random enough but I'm still able to remember them without writing them down.
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.