Recover root password

[SpruitBB]

Hello,

I've lost my root password. For security reasons also on single user mode asks mine freebsd for a root password. Is there a way to change my password?

SpruitBB

 

[SirDice]

Boot an install image, then mount the filesystems and run passwd(1) on a chroot(8) with the mounted system disk.

 

[covacat]

if you have another working account and /tmp on / (not a separate fs) you can try with init_script loader var (see init(8))
and pw usermod in the script

 

[cy@]

Depending on whether your console is secure or not, see /etc/ttys, you can boot single user and simply change your rootpw. For my lsystems I am not able to do this because:

console none                            unknown off secure

But if you see insecure in the line above within your ttys(5) file you will be able to boot single user without a password and simply change the password. Otherwise as others have suggested above use install media to edit master.passwd(5) to remove the password, reboot and set it, or chroot and change the password.

We're not able to do the same trick as Linux by changing init to /bin/bash at the grub prompt to bypass a secure console because the kernel will only allow you to use /sbin/init and an alternate hardcoded in the kernel.

Ideally one would set the rootpw and store it in a keepass database (we use keepass at $JOB and subsequently I and my wife use it at home). Then install sudo, doas, or some other method, like kerberos ksu to become root. Then only use the rootpw as needed.

Another alternative would be to store the rootpw in a sealed envelope (used at $JOB-1, stored with the security guard outside of the security serivces office that one would have to sign out).

You have a couple of workarounds plus an ongoing solution here.

 

[SirDice]

if you have another working account and /tmp on / (not a separate fs) you can try with init_script loader var (see init(8))

That's an interesting trick I did not know until now.

 

[atax1a]

We're not able to do the same trick as Linux by changing init to /bin/bash at the grub prompt to bypass a secure console because the kernel will only allow you to use /sbin/init and an alternate hardcoded in the kernel.

per init(8), the init_exec loader var "instructs init to directly execute that file as the very first action, replacing init as PID 1", so i think you could set that to /bin/sh and get the same effect as linux's init=/bin/sh.

 

[RetroComputingCollector]

6.3 in the FAQ may be helpful: https://docs.freebsd.org/en/books/faq/#misc

 

[drhowarddrfine]

This is why we will always need system engineers. I'd bet AI wouldn't know any of the solutions above.

 

[_martin]

per init(8), the init_exec loader var "instructs init to directly execute that file as the very first action, replacing init as PID 1", so i think you could set that to /bin/sh and get the same effect as linux's init=/bin/sh.

This is the best advice for SpruitBB - no hassle, just set init_exec=/bin/sh in loader and off he goes.
And psst, it bypases insecure console too.

 

[cy@]

per init(8), the init_exec loader var "instructs init to directly execute that file as the very first action, replacing init as PID 1", so i think you could set that to /bin/sh and get the same effect as linux's init=/bin/sh.

EDIT: Looks like FreeBSD is just as vulnerable to hacking as Linux is. Not good.

The only solution to this would be a boot password and protect loader.conf from prying eyes. This is similar to what one would need to do on Linux with grub2.

 

[_martin]

Output from console:

OK set init_exec=/bin/sh
set init_exec=/bin/sh
OK boot
boot
Loading kernel...
/boot/kernel/kernel text=0x17cf50 text=0xd74bd8 text=0x42ebb4 data=0x180+0xe80 data=0x1884e0+0x477b20 0x8+0x18c618+0x8+0x1b0092
Loading configured modules...
..
..
uhub2: 7 ports with 7 removable, self powered
#
# zfs set readonly=off rpool/ROOT/default
zfs set readonly=off rpool/ROOT/default
# passwd
passwd
Changing local password for root
New Password:asd

Retype New Password:asd

# grep ^con /etc/ttys
grep ^con /etc/ttys
console    none                unknown    off insecure
#

 

[atax1a]

EDIT: Looks like FreeBSD is just as vulnerable to hacking as Linux is. Not good.

physical access, absent FDE, is largely 'game over' in terms of defense. back in college we had a CD that would boot a Windows 2000 install, hotpatching the security internals, such that you could log in as Administrator with a null password.

 

[cy@]

physical access, absent FDE, is largely 'game over' in terms of defense. back in college we had a CD that would boot a Windows 2000 install, hotpatching the security internals, such that you could log in as Administrator with a null password.

Of course.

But in our datacentres with ILO and ILOM devices one doesn't need physical access. For instance I don't have physical access and even if I did, the two datacentres are 600 km and 1600 km from here. Even the staff at the datacentres have no console access as everything is web based. The ILOs and ILOMs themselves are password protected but that's merely a paper thin wrapper.

The real problem is for VMware VMs. Anyone with Vsphere access would have access to the console. Of course one would need a Vshpere login but that won't protect from the VMware team. (Over 10k Windows, Linux and Solaris servers in total.)

Physical access isn't necessarily required.

My servers are in my basement. Only my wife and I am here. Not a big deal but certainly an issue. In my case physical access is required. I have no ILO.

 

[_martin]

The real problem is for VMware VMs. Anyone with Vsphere access would have access to the console. Of course one would need a Vshpere login but that won't protect from the VMware team. (Over 10k Windows, Linux and Solaris servers in total.)

You can divide VMs into folders and set permissions on them. You can create custom roles, assign them to user and those users can be then assigned to given folders. So not true that everyone with VMware access has access to the console.

Compomising DC access - it depens. Yes, if you have servers in some SOHO, then probably you can access them more easily. We do have some servers in military base and in nuclear plants. Try to get physical access there.

 

[drhowarddrfine]

My servers are in my basement. Only my wife and I am here. Not a big deal but certainly an issue.

I understand. I often look at my wife sideways, too.

 

[cy@]

You can divide VMs into folders and set permissions on them. You can create custom roles, assign them to user and those users can be then assigned to given folders. So not true that everyone with VMware access has access to the console.

That you can do an our VMware team does this already. Our team has no access to Windows VMs while they don't have access to ours. The VMware team has access to everything.

Compomising DC access - it depens. Yes, if you have servers in some SOHO, then probably you can access them more easily. We do have some servers in military base and in nuclear plants. Try to get physical access there.