[gentoo-user] Recovering root password

[Boris Fersing]

I've revived an old Gentoo laptop, but I've forgotten the root
password. I remember the password to my user account and I can log in
there fine. Can I recover the root password?
- Grant

Hi,

boot with a liveCD, mount the gentoo partition, chroot into it and type 'passwd'

regards,

Boris.

--

[Dale]

I've revived an old Gentoo laptop, but I've forgotten the root
password. I remember the password to my user account and I can log in
there fine. Can I recover the root password?
- Grant

I think you can boot into single user mode and reset it. You have to
put it on the end of the grub boot line but I can't recall what the
exact option is. May help you search tho.

You can also boot the CD and chroot in to reset it as well. I'm sure
that will work just as well.

Dale

:-) :-)

[Florian Philipp]

Post by Dale

I've revived an old Gentoo laptop, but I've forgotten the root
password. I remember the password to my user account and I can log in
there fine. Can I recover the root password?
- Grant

I think you can boot into single user mode and reset it. You have to
put it on the end of the grub boot line but I can't recall what the
exact option is. May help you search tho.
You can also boot the CD and chroot in to reset it as well. I'm sure
that will work just as well.
Dale
:-) :-)

The option is "single" but it won't help because it requests the root
password before it gives you your /bin/bash.

Anyway, if you have sudo-rights, you can simply do "sudo passwd" and it
won't ask you for the old password.

[Alan McKinnon]

I've revived an old Gentoo laptop, but I've forgotten the root
password. I remember the password to my user account and I can log
in there fine. Can I recover the root password?

No, that would require undoing high-quality encryption schemes. Which is
a good thing, otherwise your internet banking couldn't be safe (amongst
other similar evils)

What you can do is replace the root password with something else:

Boot from any old LiveCD, mount your gentoo partitions somewhere, chroot
into them as root and run 'passwd'

If this sounds familiar, it's because it's the same process you used to
install Gentoo in the first place :-)

[Steven Lembark]

On the grub menu, edit the entry of the system you want to boot and on the
kernel line, add "init=/bin/bash" without the quotes. Boot that modded boot
instructions sequence. After kernel loads, you'll have a bash. Type: "mount
-o rw,remount /"

Make sure that your bash is statically linked,
otherwise you can run into problems with this
approach. It's acutally a good idea to keep
a static bash and just put this into grub as
the 'shell-init' or 'aaaargh' entry
(it's in their example config).

[Dirk Heinrichs]

Post by Steven Lembark
Make sure that your bash is statically linked,
otherwise you can run into problems with this
approach.

# ldd /bin/bash
linux-gate.so.1 => (0xb7f2a000)
libncurses.so.5 => /lib/libncurses.so.5 (0xb7ec7000)
libdl.so.2 => /lib/libdl.so.2 (0xb7ec3000)
libc.so.6 => /lib/libc.so.6 (0xb7d6b000)
/lib/ld-linux.so.2 (0xb7f2b000)

No need for a static bash, since everything it needs is in /lib.

Bye...

Dirk

[Neil Bothwick]

On the grub menu, edit the entry of the system you want to boot and on
the kernel line, add "init=/bin/bash" without the quotes. Boot that
modded boot instructions sequence. After kernel loads, you'll have a
bash. Type: "mount -o rw,remount /"

Or just add "rw init=/bin/sh" to avoid remounting /.

It's probably better to use a shell designed for rescue work,
like sash or busybox instead of bash, especially if /usr is on a
separate filesystem.

[Steven Lembark]

Post by Neil Bothwick
It's probably better to use a shell designed for rescue work,
like sash or busybox instead of bash, especially if /usr is on a
separate filesystem.

The statically linked bash acutally works rather
well for this. The main advantage I've found
using it for recovery situations is that I'm
used to it: sourceing root's .bash_profile is
enough to give a familiar environment.

[Grant]

I've revived an old Gentoo laptop, but I've forgotten the root
password. I remember the password to my user account and I can log in
there fine. Can I recover the root password?

On the grub menu, edit the entry of the system you want to boot and on the
kernel line, add "init=/bin/bash" without the quotes. Boot that modded boot
instructions sequence. After kernel loads, you'll have a bash. Type: "mount
-o rw,remount /"
"mount -o ro,remount /" and reboot. Done!

Done deal, thanks everyone.

- Grant

[Uwe Thiem]

I've revived an old Gentoo laptop, but I've forgotten the root
password. I remember the password to my user account and I can log
in there fine. Can I recover the root password?

If you could passwords were useless. ;-)

But you can boot from a LiveCD, mount your harddrive, chroot and then
give root another password.

Uwe

[Liviu Andronic]

Post by Uwe Thiem

I've revived an old Gentoo laptop, but I've forgotten the root
password. I remember the password to my user account and I can log
in there fine. Can I recover the root password?

If you could passwords were useless. ;-)
But you can boot from a LiveCD, mount your harddrive, chroot and then
give root another password.

But then, conventional passwords are as useless. One needs no more
than physical access to the computer, a LiveCD and a couple minutes in
order to become the super user of your system. Basically, the password
seems useful only to know whether anyone has changed it behind your
back.

I am starting to wonder why am I so attached to my root password being
strong.. :)
Liviu

[Alan McKinnon]

Post by Liviu Andronic

 But you can boot from a LiveCD, mount your harddrive, chroot and
then give root another password.

But then, conventional passwords are as useless. One needs no more
than physical access to the computer, a LiveCD and a couple minutes
in order to become the super user of your system. Basically, the
password seems useful only to know whether anyone has changed it
behind your back.

Let me guess - you own a notebook and most of your exposure to running a
computer is limited to that, and you have never administered a real
server somewhere, right?

It's very very easy to keep your servers safe from physical access
attacks - make sure the bad guys can't touch it. This is so easy to do
it's laughable - we use a locked door. The only people who have a key
are those who have to root password anyway.

On a notebook, there isn't an OS in existence that is immune to a
LiveCD. If this concerns you, apply some biometrics and encrypted
filesystem patches. Or stop using notebooks. Or stop using computers
that someone else can touch.

[Neil Bothwick]

Post by Alan McKinnon
On a notebook, there isn't an OS in existence that is immune to a
LiveCD. If this concerns you, apply some biometrics and encrypted
filesystem patches. Or stop using notebooks. Or stop using computers
that someone else can touch.

Or disable booting from the optical drive (or remove it completely) and
set a password in the BIOS. This is one of the few areas in which a
laptop has an advantage, you can't just pope the side off the case and
flip a jumper to reset the BIOS.

[Liviu Andronic]

Post by Neil Bothwick
Or disable booting from the optical drive (or remove it completely) and
set a password in the BIOS. This is one of the few areas in which a
laptop has an advantage, you can't just pope the side off the case and
flip a jumper to reset the BIOS.

I'd say the BIOS is not much of a security enforcer. Even with the
BIOS password protected, one can plug out the hardrive, connect to
another system and get access to all the data. It might need more time
than a LiveCD approach, it would be as efficient. As Alan and Wael
suggested, the approaches that can work in protecting your data are a
physical key to a locked door or a root encrypted system.
Liviu

[Neil Bothwick]

Post by Liviu Andronic
I'd say the BIOS is not much of a security enforcer. Even with the
BIOS password protected, one can plug out the hardrive, connect to
another system and get access to all the data. It might need more time
than a LiveCD approach, it would be as efficient. As Alan and Wael
suggested, the approaches that can work in protecting your data are a
physical key to a locked door or a root encrypted system.

If it is possible to have sufficient access to be able to remove the hard
drive, then an encrypted filesystem is essential. Any computer that isn't
nailed down behind a locked door should have this, unless it contains and
has access to absolutely nothing of value.

[Steven Lembark]

Post by Neil Bothwick
If it is possible to have sufficient access to be able to remove the hard
drive, then an encrypted filesystem is essential. Any computer that isn't
nailed down behind a locked door should have this, unless it contains and
has access to absolutely nothing of value.

Which setup does anyone out there use for the encfs?

[Dirk Heinrichs]

Post by Steven Lembark

Post by Neil Bothwick
If it is possible to have sufficient access to be able to remove the
hard drive, then an encrypted filesystem is essential. Any computer that
isn't nailed down behind a locked door should have this, unless it
contains and has access to absolutely nothing of value.

Which setup does anyone out there use for the encfs?

I use LUKS encrypted logical volumes. Root fs is encrypted with a password,
all other volumes are encrypted with a keyfile located on /.

Bye...

Dirk

[Wael Nasreddine]

Post by Dirk Heinrichs
I use LUKS encrypted logical volumes. Root fs is encrypted with a password,
all other volumes are encrypted with a keyfile located on /.

Why not encrypt a big fat partition and then have an LVM array over it
for all your partitions including swap ?? Suspend2 will work with this
setup just in case you are wondering.

--
Wael Nasreddine
http://wael.nasreddine.com
PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724 DE12 5565 3945 C8DD 18A2

/ö\ Slug: Peep it! The sun's already risin'. We're gonna have to blow this joint.

[Dirk Heinrichs]

Post by Wael Nasreddine

Post by Dirk Heinrichs
I use LUKS encrypted logical volumes. Root fs is encrypted with a
password, all other volumes are encrypted with a keyfile located on /.

Why not encrypt a big fat partition and then have an LVM array over it
for all your partitions including swap ??

Hmm, could do it this way also, yes.

Post by Wael Nasreddine
Suspend2 will work with this
setup just in case you are wondering.

I don't use it.

Bye...

Dirk

[Neil Bothwick]

Post by Steven Lembark
Which setup does anyone out there use for the encfs?

I use LUKS too.

[Dirk Heinrichs]

Post by Alan McKinnon
On a notebook, there isn't an OS in existence that is immune to a
LiveCD.

Linux is. In the sense that you can't get at the data if the disc is
encrypted, even not with a LiveCD. You can only destroy/overwrite it.

Bye...

Dirk

[Alan McKinnon]

Post by Dirk Heinrichs

Post by Alan McKinnon
On a notebook, there isn't an OS in existence that is immune to a
LiveCD.

Linux is. In the sense that you can't get at the data if the disc is
encrypted, even not with a LiveCD. You can only destroy/overwrite it.

Yes, I realised that when typing the original, but left it as is - too
many IF conditionals would be needed to be accurate and English is
almost useless at getting IFs to parse correctly :-)

Passwords come from a time when users had terminals that log onto
machines that are somewhere else and the user can't lay a finger on
them. Things have indeed changed since 1978

[Grant]

Post by Alan McKinnon

Post by Dirk Heinrichs

Post by Alan McKinnon
On a notebook, there isn't an OS in existence that is immune to a
LiveCD.

Linux is. In the sense that you can't get at the data if the disc is
encrypted, even not with a LiveCD. You can only destroy/overwrite it.

Yes, I realised that when typing the original, but left it as is - too
many IF conditionals would be needed to be accurate and English is
almost useless at getting IFs to parse correctly :-)
Passwords come from a time when users had terminals that log onto
machines that are somewhere else and the user can't lay a finger on
them. Things have indeed changed since 1978

Would the type of filesystem encryption you guys are talking about be
unsuitable for a high-traffic server because of performance
considerations?

- Grant

[Uwe Thiem]

Post by Grant

Post by Alan McKinnon

Post by Dirk Heinrichs

Post by Alan McKinnon
On a notebook, there isn't an OS in existence that is immune
to a LiveCD.

Linux is. In the sense that you can't get at the data if the
disc is encrypted, even not with a LiveCD. You can only
destroy/overwrite it.

Yes, I realised that when typing the original, but left it as is
- too many IF conditionals would be needed to be accurate and
English is almost useless at getting IFs to parse correctly :-)
Passwords come from a time when users had terminals that log
onto machines that are somewhere else and the user can't lay a
finger on them. Things have indeed changed since 1978

Would the type of filesystem encryption you guys are talking about
be unsuitable for a high-traffic server because of performance
considerations?

Yes, and it isn't necessary. You lock your servers away so that nobody
has physical access to them.

It's only interesting for workstations, laptops and external storage
devices.

Uwe

[Grant]

Post by Uwe Thiem

Post by Grant

Post by Alan McKinnon

Post by Dirk Heinrichs

Post by Alan McKinnon
On a notebook, there isn't an OS in existence that is immune
to a LiveCD.

Linux is. In the sense that you can't get at the data if the
disc is encrypted, even not with a LiveCD. You can only
destroy/overwrite it.

Yes, I realised that when typing the original, but left it as is
- too many IF conditionals would be needed to be accurate and
English is almost useless at getting IFs to parse correctly :-)
Passwords come from a time when users had terminals that log
onto machines that are somewhere else and the user can't lay a
finger on them. Things have indeed changed since 1978

Would the type of filesystem encryption you guys are talking about
be unsuitable for a high-traffic server because of performance
considerations?

Yes, and it isn't necessary. You lock your servers away so that nobody
has physical access to them.

Sounds like co-location right? I just have a hosted dedicated
machine. The thing that's always kept me from co-locating is hardware
failure. That would be a "my problem" in a co-located environment
rather than a "their problem" right?

- Grant

Post by Uwe Thiem
It's only interesting for workstations, laptops and external storage
devices.
Uwe

[Michael Schmarck]

Hi.

Post by Grant

Post by Uwe Thiem

Post by Grant
Would the type of filesystem encryption you guys are talking about
be unsuitable for a high-traffic server because of performance
considerations?

Yes, and it isn't necessary. You lock your servers away so that nobody
has physical access to them.

I'd rather say: "... so that only trusted people have ...". But besides
this nitpick, I agree with you.

Post by Grant
Sounds like co-location right?

No. Sounds like "build your own data center" :)

Post by Grant
I just have a hosted dedicated
machine.

This means that you've got to trust the people hosting your
environment. If you don't, then move away! You know, they
could "easily" install a traffic sniffers and whatnot.

Post by Grant
The thing that's always kept me from co-locating is hardware
failure. That would be a "my problem" in a co-located environment
rather than a "their problem" right?

Depends on your contract, but generally speaking, you're right, yes.

Michael

[Dirk Heinrichs]

Post by Uwe Thiem

Post by Grant
Would the type of filesystem encryption you guys are talking about
be unsuitable for a high-traffic server because of performance
considerations?

Yes, and it isn't necessary. You lock your servers away so that nobody
has physical access to them.

What if you sell them or give them back (leased machines)? Do you erase your
discs beforehand.

Bye...

Dirk

[Uwe Thiem]

Post by Dirk Heinrichs

Post by Uwe Thiem
Yes, and it isn't necessary. You lock your servers away so that
nobody has physical access to them.

What if you sell them or give them back (leased machines)? Do you
erase your discs beforehand.

Depends on the content of the disks. If it is sensitive, I wipe them
(not just rm or mkfs). But then, this problem has never occurred to
me. I don't lease servers, nor do I sell them. Usually, my servers
aren't sellable by the time I can't use them any more. ;-)

Uwe

[Florian Philipp]

Post by Grant

Post by Alan McKinnon

Post by Dirk Heinrichs

Post by Alan McKinnon
On a notebook, there isn't an OS in existence that is immune to a
LiveCD.

Linux is. In the sense that you can't get at the data if the disc is
encrypted, even not with a LiveCD. You can only destroy/overwrite it.

Yes, I realised that when typing the original, but left it as is - too
many IF conditionals would be needed to be accurate and English is
almost useless at getting IFs to parse correctly :-)
Passwords come from a time when users had terminals that log onto
machines that are somewhere else and the user can't lay a finger on
them. Things have indeed changed since 1978

Would the type of filesystem encryption you guys are talking about be
unsuitable for a high-traffic server because of performance
considerations?
- Grant

I did some benchmarks recently, posted them on gentoo-security. Long
story short: Even my 64bit single-core Celeron can do 256bit AES, 320bit
Anubis or 256bit Twofish faster than writing data to the disk (37MB/s).
Blowfish, CAST and Serpent are too slow.

128bit AES (which I deem good enough for the near future) causes around
40% CPU-utilization.

Whether it is suitable for your server depends on its usage patterns.

[Steven Lembark]

Post by Alan McKinnon
them. Things have indeed changed since 1978

Unless you include the time in 1972 that some of
my friends broke into the computer room, hacked
the PDP-11, and inserted "Panther, Pink" into
every class in the highschool.

They have remained hugely the same :-)

[Alan McKinnon]

Post by Steven Lembark

Post by Alan McKinnon
them. Things have indeed changed since 1978

Unless you include the time in 1972 that some of
my friends broke into the computer room, hacked
the PDP-11, and inserted "Panther, Pink" into
every class in the highschool.
They have remained hugely the same :-)

I stand corrected :-)

The technology and what people are supposed to do with computers has
changed a lot.

What wise-ass kids DO do with them has stayed exactly the same.

Sidenote: I'll expect that most of those same hacker kids are now
well-respected and competent IT professionals, right? That also hasn't
changed much over the years...

[Douglas O'Neal]

Post by Dirk Heinrichs

Post by Alan McKinnon
On a notebook, there isn't an OS in existence that is immune to a
LiveCD.

Linux is. In the sense that you can't get at the data if the disc is
encrypted, even not with a LiveCD. You can only destroy/overwrite it.
Bye...
Dirk

Depending on if you can take the system for a while then replace it,
you can still break the disc. Take the system and boot LiveCD. Modify
the kernel on the unencrypted /boot with one that records the password
entered to decrypt the other partitions. Replace the system and wait
for the user to boot, then steal it back. Possibly an unlikely series
of events but certainly not impossible.

Doug

[Wael Nasreddine]

Post by Liviu Andronic

Post by Uwe Thiem
But you can boot from a LiveCD, mount your harddrive, chroot and then
give root another password.

But then, conventional passwords are as useless. One needs no more
than physical access to the computer, a LiveCD and a couple minutes in
order to become the super user of your system. Basically, the password
seems useful only to know whether anyone has changed it behind your
back.
I am starting to wonder why am I so attached to my root password being
strong.. :)
Liviu

That's why I have my entire installation over a DM-CRYPT ( LUKS
encrypted partition... ), including swaps and storage ( LVM over
DM-CRYPT actually), this way even if someone had a physical access to
my laptop, both GRUB and LiveCD approach would be useless...
--
Wael Nasreddine
http://wael.nasreddine.com
PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724 DE12 5565 3945 C8DD 18A2

/ö\ Son, this is the only time I'm ever gonna say this. It is not okay to
/ö\ lose.
/ö\
/ö\ -- Homer Simpson
/ö\ Dead Putting Society

[Mick]

Post by Wael Nasreddine

Post by Liviu Andronic

Post by Uwe Thiem
But you can boot from a LiveCD, mount your harddrive, chroot and then
give root another password.

But then, conventional passwords are as useless. One needs no more
than physical access to the computer, a LiveCD and a couple minutes in
order to become the super user of your system. Basically, the password
seems useful only to know whether anyone has changed it behind your
back.
I am starting to wonder why am I so attached to my root password being
strong.. :)
Liviu

That's why I have my entire installation over a DM-CRYPT ( LUKS
encrypted partition... ), including swaps and storage ( LVM over
DM-CRYPT actually), this way even if someone had a physical access to
my laptop, both GRUB and LiveCD approach would be useless...

I've thought about going for this . . . and then backpedaled once more. Every
time I had a fs problem I have managed to recover to this date without much
trouble. Vanilla primary and extended partitions seem to be straight forward
to access with any LiveCD. To be honest even when I had to frig about with
LVM I managed to recover without loss of data (more out of luck than skill I
suspect). The thought however, that I may lose my private key (never say
never), or lose a drive and need to access my data pronto from a back up
makes me somewhat nervous. Should I be more brave that this?

[Wael Nasreddine]

Post by Mick

Post by Wael Nasreddine
That's why I have my entire installation over a DM-CRYPT ( LUKS
encrypted partition... ), including swaps and storage ( LVM over
DM-CRYPT actually), this way even if someone had a physical access to
my laptop, both GRUB and LiveCD approach would be useless...

I've thought about going for this . . . and then backpedaled once more. Every
time I had a fs problem I have managed to recover to this date without much
trouble. Vanilla primary and extended partitions seem to be straight forward
to access with any LiveCD. To be honest even when I had to frig about with
LVM I managed to recover without loss of data (more out of luck than skill I
suspect). The thought however, that I may lose my private key (never say
never), or lose a drive and need to access my data pronto from a back up
makes me somewhat nervous. Should I be more brave that this?

Well it depends... First of all you should know that almost every LiveCD
now include a cryptsetup/lvm implementation, Gentoo does, Ubuntu does
( not as is though you should apt-get cryptsetyp, AFAIK lvm already
installed), so recovering data would not be that hard if you can open
the partition... As for loosing the key, that's easy too, here's what
I do: I create a small file from /dev/urandom and I use it as pass key
SLOT, and store it somewhere safe, so if and when I forget all of the
passwords I have, I use this key, it is safe.

Anyway as I said above it actually depends, using dm-crypt will lower
the performance of your machine which actually make sense since the
data are encrypted before they are written to the disk (AFAIK I'm not
really sure how it handles I/O operations, but I'm sure that writing a
huge file to your HDD will result in a lot of CPU usage of the process
'kcryptd'), but using dm-crypt is very very secure, I use it because
my laptop is with me every day when I go to the university so I need
this kind of security... On the other hand if you don't need
encryption, maybe you should stick with LVM... (LVM is a must checkout
my partitions below, I love it...)

--------- CUT
# lvdisplay -C
LV VG Attr LSize Origin Snap% Move Log Copy% Convert
gentoo-opt system -wi-ao 1.00G
gentoo-overlays system -wi-ao 1.00G
gentoo-root system -wi-ao 500.00M
gentoo-usr system -wi-ao 5.00G
gentoo-var system -wi-ao 500.00M
home system -wi-ao 15.00G
storage system -wi-ao 50.66G
suspend-swap system -wi-a- 1.00G
swap system -wi-ao 2.00G
tmp system -wi-ao 500.00M
ubuntu-opt system -wi-ao 1.00G
ubuntu-root system -wi-ao 500.00M
ubuntu-usr system -wi-ao 3.50G
ubuntu-var system -wi-ao 500.00M
var-tmp system -wi-ao 100.00M
--------- CUT

Regards,

--
Wael Nasreddine
http://wael.nasreddine.com
PGP: 1024D/C8DD18A2 06F6 1622 4BC8 4CEB D724 DE12 5565 3945 C8DD 18A2

/ö\
/ö\ When Chuck Norris wants an egg, he cracks open a chicken.

[Dirk Heinrichs]

Post by Liviu Andronic

Post by Uwe Thiem

I've revived an old Gentoo laptop, but I've forgotten the root
password. I remember the password to my user account and I can log
in there fine. Can I recover the root password?

If you could passwords were useless. ;-)
But you can boot from a LiveCD, mount your harddrive, chroot and then
give root another password.

But then, conventional passwords are as useless. One needs no more
than physical access to the computer, a LiveCD and a couple minutes in
order to become the super user of your system. Basically, the password
seems useful only to know whether anyone has changed it behind your
back.

That's only true if you didn't do anything else to protect the system. All
the above is useless if the / filesystem is encrypted.

Post by Liviu Andronic
I am starting to wonder why am I so attached to my root password being
strong.. :)

Because it protects your system from abuse.

Bye...

Dirk

[Steven Lembark]

Post by Liviu Andronic
I am starting to wonder why am I so attached to my root password being
strong.. :)

Becuase I can crack a simple password from outside
of the box. Hacking in w/ a CD or the init=blah
approach requires physical access and a reboot,
both of which are fairly noticable and preventable.