# verifying password for geli



## eydaimon (Nov 21, 2016)

The last two times when booting my machine, the passphrase has taken me a lot of work to get past.  As of recent, I have to hit the enter key to get the proper prompt, but what used to be simply entering the password now takes many many tries to the point where I'm no longer confident of entering the correct password. I've added kern.geom.eli.visible passphrase=1 to loader.conf so I can see it next reboot but I also want to validate my password.

Since this is on the root, it seems I can't simply detach the root drive and then attach just to see if the password is correct, and I don't want to do that anyway.

1. Is there a way I can check my password?
2. if there's an issue for whatever reason, how I can remove the whole encryption so that I can still boot like expected?


----------



## Remington (Nov 21, 2016)

1. The only way to check is to change the password. It won't reveal the password to you as its encrypted.
2. You will have to copy everything out of the encrypted partition before you can delete it or boot the encrypted partition with a key so you don't have to manually enter it every time it boots.


----------



## Petr Fischer (Nov 21, 2016)

add to loader.conf this:


```
geom_eli_passphrase_prompt="YES"
```

On boot, you will be asked for password in very beginning stage - but in this stage, password can't be validated, because there is no devices detected at all (on boot start). But password prompt will not be lost in other boot messages.


----------



## eydaimon (Nov 21, 2016)

Given the loader.conf:


```
geli_ada0p4_keyfile0_load="YES"
geli_ada0p4_keyfile0_type="ada0p4:geli_keyfile0"
geli_ada0p4_keyfile0_name="/boot/encryption.key"
```


Is the command to change the password simply:

`geli setkey -k /boot/encryption.key /dev/ada0p4` ?


----------



## eydaimon (Nov 23, 2016)

Anyone?


----------



## ANOKNUSA (Nov 23, 2016)

eydaimon said:


> mand to change the password simply:
> 
> `geli setkey -k /boot/encryption.key /dev/ada0p4`?



You can add `-n <key_number>` to specify which slot you're writing they key/passphrase to. So `geli setkey -n 1 [other stuff]` would write a new key/passphrase to the second slot on the partition; slot 0 is the default slot, and will be used if the slot is not specified on the command line. By specifying slot 1 you could add a second passphrase to the partition and, once you're sure it works, delete the original key.

In answer to your original question, no, there's no way to retrieve the passphrase for GELI. Forget your passphrase, and the data's gone.


----------



## eydaimon (Nov 23, 2016)

Thanks ANOKNUSA    does that mean I can use either of the passphrases during boot, or how can I make sure it works?


----------



## ANOKNUSA (Nov 24, 2016)

Yes, either passphrase should work. However, keyfiles work differently. A passphrase can only be tied to one keyfile, so if you use a keyfile along with the passphrase, things get a bit more complicated.

I've also edited my post above to correct the slot numbering: slot *0* is the primary slot; slot *1*, the secondary slot. There is no slot 2. Thankfully my mistake wouldn't (shouldn't?) have caused any harm, but it was still a stupid one to make.


----------



## eydaimon (Nov 24, 2016)

Cool  Thank you much


----------



## eydaimon (Nov 24, 2016)

Will I need to use the -g  flag for this? to ensure I can boot from it when using -n 1  incase the first password is indeed a problem?


----------



## ANOKNUSA (Nov 25, 2016)

eydaimon said:


> Will I need to use the -g flag for this?



If the system has been booting up to this point, then probably not. The "-g" flag is a new addition to geli(8) as of 11.0-RELEASE. It allows you to boot from a fully encrypted disk, without the need for an unencrypted boot/system partition. Unless you have an encrypted system partition (which would have required you to use that flag the first time around), you won't need it this time.

Also, I've taken this for granted so far, and you probably already know this, but just in case: always be sure you have a good backup before messing around with disk encryption.


----------

