Testing Encrypted disk volume password without unmounting volume

Kai

Kai

Hi there, I have a bit of a strange request. Does anyone know of an easy way to "test" the password of an encrypted volume against it's key? I mayyyy have created a box with an encrypted GELI root about a year ago, mounted it, booted the box and then not touched it since.

Now I have to physically move the box and I'm 99% sure I know the encrypted root disk GELI password but I'm vaguely terrified to turn it off in case of that 1%.

Is there any way, from the command line, that anyone can think of that I could "test" my password. Either by just trying to decrypt the encryption key or doing something that will prompt me for my passphrase, check it and tell me it's correct but not unmount of break the running disk?

Any help would be much appreciated. If there isn't a way I'll just do a full backup before powercycling and bite the bullet but I'd like to avoid the extra work if there is an easy command line way to test the password.

Kai
 
There's no way to test the passphrase without detaching first. However, you can set a new passphrase while your geli is attached. It won't ask for old passphrase unless if geli is detached.

Do this...
geli setkey /dev/name

Then it will ask you to enter new passphrase twice then that's it.
 
You are my own personal hero. Do I have to generate any kind of new key? How do I find out what the device is that's encypted?

I used geli list and got the following.

geli list

Geom name: vtbd0p4.eli

State: ACTIVE

EncryptionAlgorithm: AES-XTS

KeyLength: 256

Crypto: hardware

Version: 7

UsedKey: 0

Flags: BOOT

KeysAllocated: 11

KeysTotal: 11

Providers:

1. Name: vtbd0p4.eli

Mediasize: 44021313536 (41G)

Sectorsize: 4096

Mode: r1w1e1

Consumers:

1. Name: vtbd0p4

Mediasize: 44021317632 (41G)

Sectorsize: 512

Stripesize: 0

Stripeoffset: 1048576

Mode: r1w1e1


Geom name: vtbd0p3.eli

State: ACTIVE

EncryptionAlgorithm: AES-XTS

KeyLength: 128

Crypto: hardware

Version: 7

Flags: ONETIME, W-DETACH, W-OPEN

KeysAllocated: 1

KeysTotal: 1

Providers:

1. Name: vtbd0p3.eli

Mediasize: 2147483648 (2.0G)

Sectorsize: 4096

Mode: r1w1e0

Consumers:

1. Name: vtbd0p3

Mediasize: 2147483648 (2.0G)

Sectorsize: 512

Stripesize: 0

Stripeoffset: 2148532224

Mode: r1w1e1


and in dev

nicodemus ~ # ls /dev/vtbd0p

vtbd0p1 vtbd0p2 vtbd0p3 vtbd0p3.eli vtbd0p4 vtbd0p4.eli

nicodemus ~ # ls /dev/vtbd0p

Do I do it to the .eli disks or the raw p3/p4
 
I basically used the freebsd "encrypt root" at install option and provided a passphrase. So that's all I did.

Kai
 
So you will do something like this but first it might be good idea to backup your data. The reason is I don't know if the FreeBSD "encrypt root" at install adds the key as well. Does your /etc/rc.conf show any geli parameters?

geli setkey /dev/vtbd0p3
geli setkey /dev/vtbd0p4
 
Fortunately I decided to test this quickly with a Virtual Machine with a quick freebsd install on it installed as above.

root@test:~ # geli setkey /dev/da0p3
geli: Cannot read metadata from /dev/da0p3: Invalid argument.
root@test:~ # geli setkey /dev/da0p4
Enter passphrase:

Using the command you supplied worked to change the password for da0p4 but gives me an error for p3 (above) which seems to indicate it's not an encrypted partition. Just changed p4 to "changeme" and rebooted. It asked for the password at boot which is fine as normal. But got halfway throguh the boot process and stopped and asked for the password again.

uhub2: 7 ports with 7 removable,self powered
Enter passphrase for da0p4: *I entered new password here*
GEOM_ELI: wrong key for da0p4. tries left: 2.
Enter passphrase for da0p4: *I entered old password here*
GEOM_ELI: wrong key for da0p4. tries left: 1.
Enter passphrase for da0p4: *I entered new password here*
GEOM_ELI: wrong key for da0p4. tries left: no tries left
Enter passphrase for zfs0: *I entered new password here*
<boots>

On the last wrong password attempt it asked the first time for a password for "zfs0" and the new password worked and it booted as normal. But now each time it askes for the password for da0p4 and it never works, but one it gets the 3rd wrong answer boots automatically. Almost like it cached the answer for zfs0 the first time. And now a geli list shows the below instead of da0p4. But everything system wise LOOKS normal. Seems weird.

$ geli list

Geom name: gpt/zfs0.eli
State: ACTIVE
EncryptionAlgorithm: AES-XTS
KeyLength: 256
Crypto: hardware
Version: 7
UsedKey: 0
Flags: BOOT
KeysAllocated: 4
KeysTotal: 4
Providers:
1. Name: gpt/zfs0.eli
Mediasize: 17177767936 (16G)
Sectorsize: 4096
Mode: r1w1e1
Consumers:
1. Name: gpt/zfs0
Mediasize: 17177772032 (16G)
Sectorsize: 512
Stripesize: 0
Stripeoffset: 1048576
Mode: r1w1e1
 
You must log in or register to reply here.
Back
Top