# Testing Encrypted disk volume password without unmounting volume



## Kai (Jul 7, 2016)

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


----------



## Remington (Jul 7, 2016)

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.


----------



## Kai (Jul 7, 2016)

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.

[FONT=Courier New]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[/FONT]


and in dev

[FONT=Courier New]nicodemus ~ # ls /dev/vtbd0p

vtbd0p1      vtbd0p2      vtbd0p3      vtbd0p3.eli  vtbd0p4      vtbd0p4.eli  

nicodemus ~ # ls /dev/vtbd0p
[/FONT]
[FONT=Arial]Do I do it to the .eli disks or the raw p3/p4[/FONT]


----------



## Remington (Jul 7, 2016)

So you have two encrypted volumes and did you use the key + passphrase or only the passphrase when you set it up?


----------



## Kai (Jul 7, 2016)

I basically used the freebsd "encrypt root" at install option and provided a passphrase. So that's all I did. 

Kai


----------



## Remington (Jul 7, 2016)

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`


----------



## Kai (Jul 7, 2016)

Nope. None. Just the ones I've put in for DHCP and web servers.


----------



## Kai (Jul 7, 2016)

Fortunately I decided to test this quickly with a Virtual Machine with a quick freebsd install on it installed as above.

[FONT=Courier New]root@test:~ # geli setkey /dev/da0p3
geli: Cannot read metadata from /dev/da0p3: Invalid argument.
root@test:~ # geli setkey /dev/da0p4
Enter passphrase: [/FONT]

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.

[FONT=Courier New]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.
[FONT=Courier New]Enter passphrase for da0p4: *I entered old password here*
GEOM_ELI: wrong key for da0p4. tries left: 1.
[FONT=Courier New]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>[/FONT][/FONT][/FONT]
[FONT=Arial]
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.[/FONT]

[FONT=Courier New]$ 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[/FONT]


----------

