Security

Recover FreeBSD root access when you forgot the password

Losing your root password is not necessarily the end of the world. Single User Mode offers the solution to a lost root password.

Using a decent password management system can help ensure that you can use unique, strong passwords for everything that needs a password, without having to worry about forgetting or losing your passwords. No matter how many passwords are stored in your password management system, you only need to recall the password you use to access the password manager; it does the rest of the remembering for you. Many password manager options exist, including my current favorite, pwsafe -- which can be used as a keyboard shortcut driven X tool with the application of just a little ingenuity.

There are times you may not want to use a password management system to store a password, however. Some might argue against the wisdom of storing the root password for a Unix system within a password management tool run on that system, for instance. If you are bothered by the prospect of storing the root password in your password manager's database, you still have to contend with the task of remembering that password on your own.

We use passwords very regularly in our day-to-day computing lives, such as when logging into any of dozens of Websites we may visit daily or even many times a day. Because of that, chances are good that anyone using a password management system to store passwords will have to type in the password for that password manager quite often. As a result, the possibility of forgetting that password (short of blunt force trauma to the head) is effectively nonexistent for the majority of us. In cases such as maintaining a FreeBSD file server that basically never needs maintenance or rebooting, however, the system's root password might be much more easily forgotten. Months at a time between uses of a password is not a schedule designed to engrave it on the forefront of one's brain.

Combining rare usage of the root password with a reluctance to store it in a password manager could be a recipe for disaster. It would be a tremendous shame to have to reinstall an OS just because of a failure to remember a password. Luckily, there are often ways around this problem. In FreeBSD, you should be able to recover root access when you have forgotten the root password by following these steps:

  1. Restart the system.
  2. At the boot: prompt, enter boot -s to enter Single User Mode.
  3. When asked what shell to use, press the Enter key.
  4. Because the root filesystem will be mounted read-only by default, you will need to remount it using the mount -ruw / command to give yourself read/write access.
  5. Run mount -a to remount all filesystems specified in the /etc/fstab file.
  6. Run passwd root to set a new root password.
  7. Run exit to continue booting normally.

This time, you should consider how you intend to avoid losing the root password . . . again.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

26 comments
seanferd
seanferd

Some might argue against the wisdom of storing the root password for a Unix system within a password management tool run on that system, for instance. Duh, just keep all the important passwords on your smart phone. Problem solved. /sarcasm

wizard57m-cnet
wizard57m-cnet

Did you just tell everyone how to bypass any root security on a FreeBSD system? If they have physical access to your FreeBSD system, they now have the tools to pwn it. Not very secure. This is as insecure as some of the recent Windows malwares that require physical access to be effective. Wouldn't a more prudent method be to keep the password somewhere, in a safe maybe, for the just in case I forget time, rather than have a system that now ANYBODY that has access to the keyboard can overcome just be resetting the password?

martian
martian

Let's face it. If anyone can get physical access to a box, it's not yours anymore. The only way to prevent that is via physical security. And this is definitely NOT exclusive to any OS, whether it is a BSD variant, Linux, Windows or Apple. Great article as usual, Chad.

quinn.rm
quinn.rm

Setting the console to insecure in /etc/ttys will cause FreeBSD to ask for a password when booting into single mode. When this is set, the machine will need to be booted from a bootable disk/disc for the password to be reset. Here is a better article and discussion on the subject: http://www.cyberciti.biz/tips/howto-freebsd-reset-recover-root-password.html Obscurity is not security. There may be people who don't know about this, and it could cause them to rethink their setup (IP KVMs, builtin console redirection). It's better to have this knowledge out there then to leave it in the dark. If someone has physical access to the location and console access to the server, you're toast anyway.

robo_dev
robo_dev

It's great to know how to get root on any UNIX box, just not so sure that the purpose of TR is to help out every script kiddie who picked the lock to your server room.

apotheon
apotheon

> Did you just tell everyone how to bypass any root security on a FreeBSD system? The same kind of thing can be done on pretty much any OS, including Linux-based systems. Go ahead, look it up on Google. I'll wait. Are you done? Okay, then I'll continue. Of course, there are ways to prevent that. For instance, raising the "securelevel" (not a feature of Linux-based systems) of your FreeBSD system can prevent it. Using volume encryption can also prevent the step where the root directory is remounted, thus also stopping someone from changing your root password. > Wouldn't a more prudent method be to keep the password somewhere, in a safe maybe, for the just in case I forget time, rather than have a system that now ANYBODY that has access to the keyboard can overcome just be resetting the password? A better way to do it would be to use one of the many options available for prohibiting this action, coupled with keeping your root password in a good password manager like pwsafe. Some people don't like that, though, and would rather just be able to reset the root password if they forget it. Sometimes, I guess physical security is handled in other ways. On the plus side, at least you'd know the system has been compromised when you realized the root password has been changed.

kama410
kama410

Excellent article Chad, as usual. I knew there was a way to prevent booting in single mode to get around the root PW, but I haven't been messing around with BSD for a while and had forgotten. For the detractors: I'll put this plainly; as quinn.rm says, "If someone has physical access to the location and console access to the server, you're toast anyway." If you are allowing access to your server by people you don't trust, you have much bigger issues than keeping this a secret will solve. This trick was just about the first thing I learned about FreeBSD, setting the console to insecure was the second. If you think this is some big secret you haven't read the FreeBSD manual and you probably don't have any business making moral judgments about things you know nothing about.

tbmay
tbmay

You nailed it. I might not agree with Chad on the definition of software religion, but we generally do see eye-to-eye on matters of security. There are a lot of propeller heads who haven't learned one size does NOT fit all on matters of ANYTHING...including security. If your server is in a secure physical location, allowing single user mode is a good idea just in case you do what I've done before...forget it. Yes, I have had to reset root on an OpenBSD firewall. If you're using a BSD based laptop and it's likely to get stolen, encrypted volumes is a good idea.

apotheon
apotheon

What do you mean about it being against forum rules for the article to be a question? > not so sure that the purpose of TR is to help out every script kiddie who picked the lock to your server room. Are you one of those people who thinks that refraining from talking about security issues is a good way to keep things secure?

wizard57m-cnet
wizard57m-cnet

That's more or less "common knowledge" for most of us. It's been a number of years...7 or 8 now...but I used to do a bit of maintainence on an AIX 4.1 system. I don't remember this particular "feature" of AIX, to gain "root" you had to have the installation media (disk, tape, etc.). Since we didn't forget our root password, we never had occassion to bypass the security, if it was possible, without the installation media. Possessing the installation media back in those days, we didn't have high speed internet access to download something from a torrent or such, presumed you were the licensee, and therefore were entitled to root access. But look on the plus side...since FreeBSD is such a small player, few would be interested in rooting your server, even if they somehow came in actual physical possession of it.

Sterling chip Camden
Sterling chip Camden

I've often wondered about the trade-off between preventing single-user access vs the convenience of having it. Is there a way to require the root password for it? When I was at a conference last week, I left my computer running on a break on more than one occasion. I locked it using the instructions you provided in a previous article, but I realized that if someone really wanted in all they'd have to do is reboot it and go into single-user mode. How would I prevent that without making it impossible to do system maintenance?

apotheon
apotheon

Evangelism. I definitely recall that. No biggie. I think our disagreement over the uses of that term, and of "marketing", is a very very small matter in the grand scheme of things.

tbmay
tbmay

My bad... Yeah we debated that in another thread :)

apotheon
apotheon

> I might not agree with Chad on the definition of software religion, but we generally do see eye-to-eye on matters of security. Is this a reference to a specific earlier discussion or article? Nothing leaps to mind at the moment, so I'm curious about your meaning. Thanks for the vote of confidence on matters of security, by the way.

kama410
kama410

If your server room is under lock-and-key you might want to actually allow single user mode. This is handy if you forget. Trust one who has. wink LOL. Yes, that would be how I learned what single user mode was on my first Linux install. If your server room isn't locked up (and maybe put a good camera or two in there) then you must really trust the other people in the building.

tbmay
tbmay

If your server room is under lock-and-key you might want to actually allow single user mode. This is handy if you forget. Trust one who has. ;) Same deal with Linux systems. Server under lock-and-key, leave grub "unpass'ed" Put a password on any laptop you think might get stolen...or any machine at all for which you really need to keep the console locked....and use encrypted volumes.

apotheon
apotheon

I'd say the "rules" should be interpreted more as disallowing giving script kiddies direct answers to blatantly obvious attempts to learn how to use "1337 h4xx0rz", just as they should be interpreted as disallowing doing CompSci students' homework for them.

robo_dev
robo_dev

On TR I could give volumes of great posts about how to side-step the security controls of many systems. My only point is that I was under the impression that the forum rules made discussion of such matters taboo, forbidden, verboten. I don't believe in security through obscurity, but I have respect for ground rules, that's all. :)

apotheon
apotheon

> I suppose, as the author, you have to respond to comments about your article, even asinine, lame accusations. I guess I don't have to, but I feel kind of compelled to respond to feedback as much as time permits. > You might want to add the info about setting the console to insecure to prevent booting to single mode without a PW. I was actually thinking about addressing that in a separate article.

kama410
kama410

An excellent and valuable article, as usual. I suppose, as the author, you have to respond to comments about your article, even asinine, lame accusations. You might want to add the info about setting the console to insecure to prevent booting to single mode without a PW.

apotheon
apotheon

There are several reasons I did not know what was meant: 1. This is not an answer to a blatantly obvious request for malicious security cracking information. It's helpful information for people who have screwed up their system administration tasks and need help. 2. This information is very rarely useful to malicious security crackers. 3. There are trivially simple ways to avoid having this problem, which were mentioned in the article. 4. There are ways to guard against misuse of this information. 5. This information is far from secret, anyway. 6. I do not actually visit the question forums much these days. I find I'm able to help more people more quickly on several mailing lists than I am wasting my time on the forum here. 7. There are much easier, and more widely known, ways to gain the same level of access to the system -- such as booting off a LiveCD. 8. Once you're doing things like changing someone's root password, you might as well just pull the hard drive and connect it to a separate computer. You probably don't want to get caught in the middle of doing this at the system in question, anyway. 9. The bad guys already know -- so shouldn't you know about it, too? Obscurity is not security. 10. I do not tend to assume people are stupid, which is what is needed to think this article presents some kind of security risk. edits: I keep thinking of more reasons that's an asinine, lame accusation about the character of this article.

ancient.drive
ancient.drive

my teacher used to say the only secure system is one that is not connected and under lock and key.

seanferd
seanferd

And yes, at least on one occasion, I have seen the author of an article lambasted by one or two community members. The way I look at it, articles are one thing, but giving a computer thief or malicious cracker step-by-step instructions in the forum is another game entirely. (And yes, I know many people asking probably are fully legitimate in their quest for such information.) But for the malicious types, who can somehow manage to sign up to post at TR, yet are fully incapable of using a search engine or even reading the existing articles at this site, it is apparently a showstopper if one simply does not answer their questions. Then there is also the aspect that the TR PTB have allowed such articles, but the Community has chosen not to answer such questions. This is easier overall than attempting to vet all such questions and any answers given. It also avoid building a culture that includes idiot crackers in the forum. Anyhoo, that's my take on it.

Neon Samurai
Neon Samurai

A boot partition is usually around 256 meg; put it on an SD if your notebook has an SD slot you don't use frequently. Based on my knowledge of LVM, I'm guessing that your hard disk encryption app exists in the boot loader/boot partition area. When the SD is plugged in, BIOS trips the boot process and you enter your HDD encryption password. When the SD is not plugged in (ie. in your pocket, with your keys, somewhere secure), the BIOS won't even find a boot loader to trigger let alone have the software to decrypt your HDD. (This negates Evil Maid type attacks provided you don't leave your SD or notebook with booted SD unattended)

apotheon
apotheon

One approach is to use full volume encryption on the computer -- something you should probably do with a laptop you take on business trips and vacations, anyway. If you need a password to access the filesystem where the root password is stored, nobody can change the root password (even in Single User mode) without the encrypted filesystem's password.