Solved Locked out of console, cannot reset in single user mode

I'm running FreeBSD 11.4. Looks like I made a rookie mistake...

I was reading chapter 7 in Absolute FreeBSD by Michael Lucas and I tried a couple of the examples for /etc/login.access

My rules:
Code:
+:wheel:console
+:wheel:192.168.0.
-:ALL:ALL

And it works... kinda.
I CAN log in from another machine on my local network with my non-root wheel user, but...
I CANNOT su from that user
I CANNOT login as root from the console (it says my password is wrong but it's not)

So, I rebooted the server into single user mode, and I tried:
Code:
# mount -u /
mount: /dev/mfid0s1a: R/W mount of / denied. Filesystem is not clean
- run fsck. Forced mount will invalidate journal contents: Operation
not permitted

How can I remove those rules from login.access?

thanks
 
Did you run fsck?
No I didn't at first because I wasn't sure if that was a good idea.

I looked it up first, then ran fsck.

Next, I tried mount -u / again and it worked!

Then I just did mv /etc/login.access /etc/login.access.old

Now everything works again.

That'll teach me
 
It should :)
We've all done stupid things, that's how you learn.
It's often handy to have a bootable "live cd"/installer image on hand. You can boot that and then do a lot of things to fix systems.
fsck fixed the errors very quickly. I think these errors may have been caused by a lengthy power out at our office building. The server is on a battery backup but the power was out for several hours.

I DO have the FreeBSD installer on a USB stick, which is how I installed it originally. I was wondering if that was going to be my next step.

I'm still wondering about the functionality and usefulness of login.access. Wouldn't it be better to just have rules in sshd_config? or firewall rules? The author of Absolute FreeBSD makes login.access sound like a great feature.
 
My opinions:
Security is best when you have multiple tools available. login.access is a tool that you can use when it fits your needs. Personally, I've never had a need to use it. But I would think that physical console access is the best use for it: deny all except root on the console.

Remote access: I think sshd configuration is a better place for that kind of control, firewall rules to allow from specific IPs is even better, especially when you write firewall rules starting with "default deny".
login.access is a tool for enhancing system security, sshd, firewalls, securelevel sysctl (be careful with this one!) all tools that if you are aware of them, you can pick the one that fits your needs.

The message you got is definitely "the machine didn't shutdown cleanly at some point", but I would have thought the next boot that should have been cleaned up. I notice /dev/mfi: that's one of the hardware RAID controllers, isn't it?

If you have systems on an UPS, make sure that the shutdown procedure actually works. You may have to play around with some of the timing numbers based on the load, maybe do shutdown when there is 5 mins of runtime left instead of 3mins.
 
I notice /dev/mfi: that's one of the hardware RAID controllers, isn't it?
Yes, I have 2 disks in RAID 1. Like you, I thought the next boot after a power failure would have cleaned things up as well. The server DID come back up automatically as soon as the power came back on, and everything on the server worked fine, so I didn't think about it.

Thanks for all the tips! I don't think I'm going to mess with login.access any more at the moment. I'm going to focus on sshd_config and firewall rules.
 
fsck fixed the errors very quickly. I think these errors may have been caused by a lengthy power out at our office building.
It's not the length of the power outage that was the problem. It was the fact the system was powered down without a proper shutdown. If you shutdown the machine during a write you can get filesystem corruption. At the very least the filesystem is marked "dirty" because it wasn't shutdown properly. That's why you needed to run fsck(8), it fixes any filesystem errors and marks the filesystem as "clean".

The server is on a battery backup but the power was out for several hours.
The point of a battery backup is to overcome short power outages or, when the outage is longer than the battery can provide for, do a graceful shutdown of the machine.
 
Back
Top