Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Recently, i installed FreeBSD for work and geli for encryption. (Full disk encyrption without boot partition.) When I finished getting it setup, I found that every time it boots, I need to enter the parse password to mount the root disk.

This is not for my needs. I just want my system to boot automatically, so i can ssh to it. But when others shutdown my machine, and try to use another freeBSD system to mount my disk, they can't. If they mount the partition with another FreeBSD system, they can only see /boot dir. All files are secure!

Is my concept possible? (To have an encrypted system boot automatically if mounted by another system?) And if so, how do I do it with freeBSD?

share|improve this question
You want to boot automatically? No encryption. You want to encrypt it? No automatic boot. Those are your only options; pick your poison. – HopelessN00b Jul 31 '12 at 14:43
up vote 2 down vote accepted

tl:dr: No

If you want the key to be used automatically on boot then the key must be accessible on boot. Which means on the unencrypted part of the disk.

If it is on the unencrypted part of the disk then other can take the disk out of your system, read the key and decrypt the rest of the disk.

There is no way to properly protect the disk and not to store the key.

share|improve this answer
He could, in principle, keep the key in some other place, like the nonvolatile memory that goes with the firmware. That would stop anyone being able to mount the disk on another machine, but would still allow walk-up access. It's still not a very good idea, though. – Tom Anderson Aug 1 '12 at 12:18
nonvolatile memory is a good idea. Personally I considered a pen drive in the USB plug, which is on many server style motherboards. But ultimately it comes down to two choices: 1) secure. 2) Fully bootable without entering a password. Where ever you store the pass phrase can be obscured, but it will never be completely safe. – Hennes Aug 1 '12 at 13:09

No. If you wish to decrypt it automatically, you need to have your password stored on the disk in cleartext, or obscured in some (bad) way. Someone with enough willpower will be ably to get that password easily. If only "/boot" is unencrypted, the password has to be there, and the attacker just has to find it.

If you just don't wish to be physically present to unlock the server, it could be solved by having an unencrypted system installation, which would boot, start services like ssh which would enable you to unlock the data partition from a remote location.

share|improve this answer
...or get an IP KVM setup that would allow you to console in to enter the boot password remotely. – HopelessN00b Jul 31 '12 at 14:42
This is most likely a workstation or laptop, not a server the way a professional sysadmin would think of a server. – Michael Hampton Jul 31 '12 at 15:42

I've had a similar problem, which I solve by only encrypting /home. The trouble is /etc/rc.d/geli wants to mount it before continuing with the boot. A kludge would be the do the mount manually post-boot, but I like the way in which it proposes to do it at boot time - I just want the network to start first, since /, /var and /usr aren't encrypted.

I thus put this:

/dev/ada0p7.eli /home ufs rw,noauto 0 0

in /etc/fstab

Created matching "l" options in rc.conf: lgeli_devices="ada0p7" lgeli_ada0p7_flags="-k /etc/geli/server.key" lgeli_ada0p7_autodetach="NO"

and then lgeli in /etc/rc.d, like so:


# PROVIDE: lgeli
# REQUIRE: sshd
# KEYWORD: nojail

. /etc/rc.subr

        local devices devices2
        local provider


        for provider in ${devices}; do
                devices2="${devices2} ${provider}"

        echo ${devices2}

start_precmd='[ -n "$(lgeli_make_list)" ]'


        if [ -z "${lgeli_tries}" ]; then
                if [ -n "${lgeli_attach_attempts}" ]; then
                        # Compatibility with rc.d/gbde.
                        lgeli_tries=`${SYSCTL_N} kern.geom.eli.tries`

        for provider in ${devices}; do
                provider_=`ltr ${provider} '/-' '_'`

                eval "flags=\${lgeli_${provider_}_flags}"
                if [ -z "${flags}" ]; then
                if [ -e "/dev/${provider}" -a ! -e "/dev/${provider}.eli" ]; then
                        echo "Configuring Disk Encryption for ${provider}."
                        while [ ${count} -le ${lgeli_tries} ]; do
                                geli attach ${flags} ${provider}
                                if [ -e "/dev/${provider}.eli" ]; then
                                        # LOUIS line below, so long as
                                        # /etc/fstab... noauto line
                                        # present, this works
                                        mount "/dev/${provider}.eli"
                                echo "Attach failed; attempt ${count} of ${lgeli_tries}."


        for provider in ${devices}; do
                if [ -e "/dev/${provider}.eli" ]; then
                        umount "/dev/${provider}.eli" 2>/dev/null
                        geli detach "${provider}"

load_rc_config $name
run_rc_command "$1"

This way, it's fairly clean, and not too much of a kludge. The mount command in lgeli ensures that the noauto stuff is mounted if geli'd. A bit ugly, but to me the main thing is, I can log in remotely and rescue my desktop from being inaccessible after a power failure, which was the default mode otherwise!

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.