Encrypted hard drive asking for password every time

Kinda curious as to the point of drive encryption if you just want it to automatically unlock on boot.

Encryption makes it more difficult to copy data from the drive. Windows and MacOS can manage to encrypt drives without requiring two different passwords, I mistakenly assumed Linux could too.
- If you're having it automatically unlock the drive at boot, it kind of defeats the purpose. If someone steals your tower, they can boot it and copy the unencrypted contents since it automatically unlocks.
- But if you have it set to unlock automatically…? It’s not like the drive is going to know it’s you booting it vs someone else if you’re not having to enter the password.
  Windows and Mac can indeed encrypt drives without two passwords - as long as you don’t set a drive encryption password to be entered at BIOS load before the OS loads, which is what you’ve done.
- How... How would they get the drive? Would n that need access to your computer? I imagine at that point they could turn it on first and copy your data that way, no?

It's disappointing to see so many commentors arguing against you wanting to do this. Windows has it through bitlocker which is secured via the TPM as you know. Yes it can be bypassed, but it's all about your threat level and effort into mitigating it.

I am currently using a TPM on my opensuse tumbleweed machine to auto unencrypt my drive during boot. What you want to do is possible, but not widely supported (yet). Unfortunately, the best I can do is point you to the section in the opensuse wiki that worked for me.

https://en.opensuse.org/SDB:Encrypted_root_file_system

If you scroll down on that page you'll see the section about TPM support. I don't know how well it will play with your OS. As always, back up all your files before messing with hard drive encryption. Best of luck!

Sums up about every thread asking how to do something on Linux, 30 different responses on how the OP is wrong and shouldn't do it that way.
- To be fair there are probably many different ways to solve the problem. I'm somewhat experienced with Linux and I've attempted seeing up TPM LUKS decryption on boot. It's certainly not easy or at least wasn't when I tried. For non experienced people it's easier to just enter the password at boot and enable auto login. Then you get the security, software, ethics, or licensing debates that accompany most Linux discussions.
Thanks, Zorin is based on Ubuntu so I have to assume it will be up to date with stuff like TPM which is 15 years old. The data on the page you linked is pretty advanced for me but I'll give it a shot. Appreciate you addressing my question.
- Ubuntu isn't really on the cutting edge, so I'm not sure how well its going to work. Opensuse tumbleweed is running pretty much the latest everything, so its possible youll need to wait until the next Ubuntu lts
Windows is no baseline for security lol
Yeah, holy shit is this comment section toxic. Why are people downvoting for someone asking for help and not being a dick?
Is this whole community like this? Are the mods okay with this behavior?
This is also what I would recommend and is most similar to the windows experience

OP, just change your encryption key to whatever you have your password as and set your login to auto login. This will give you the experience you desire as it'll decrypt the disk with your password and log you in automatically once it's decrypted, but if you lock the system (close the lid. Screen lock. Etc) you'll still get a login screen as normal. (Just keep in mind they're technically two separate passwords and will unfortunately need to be changed separately if you do change your password).

What I do for a little extra security is that my encryption password is just a longer variation of my normal password. So of I have an encrypted password sentence like "correct battery staple horse" my login password would just be "correct battery". It's a simple way to add a little extra and a good reminder everytime I turn on my computer that they are in fact two different passwords and protect me differently.
This is solid advice

You ended up with full disk encryption. For most people, it's the simple option, everything is encrypted. That means the OS can't start without the key, because you're the only holder of the key. It's both dead simple, and pretty bulletproof since there's no way to access the system without the password. But as you said, not everyone wants that.

What you're asking for is an encrypted home directory. It's not that Linux can't do it, it's just not what you got. Depending on the use case you can either use TPM to unlock the root partition to boot, or not encrypt the system itself. Then when you log in, it decrypts a separate partition (or use ZFS native encryption, or use fscrypt if your filesystem supports it, or use an overlay filesystem like go-cryptfs).

So it's not that Linux doesn't support your use case but rather your distro doesn't offer it as an installation option. From there you either configure it yourself (ArchWiki is great regardless of distro), or seek out a distro that does.

Linux is not an operating system, it's just the kernel. What makes it an OS is what distros build on top of it. Linux alone is not that useful, hence the basis of the GNU+Linux memes: it's Linux, plus a lot of GNU tools to make it do useful things, plus a desktop environment and a whole bunch of other libraries and applications, plus the distro's touch tying it all together in a mostly cohesive experience.

- Fprintd is the only biometrics I know and hardware support is very limited. There are no easily accessible usb fingerprint readers either, which would allow easy testing and recommending.
  I think if we could reverse engineer some kensington / etc. fprint sensor that would be huge.
But I'm confused, the decryption of the home directory needs the owners secret to be entered at some point? I don't see how this solves Op's problem (which I also don't understand, you want encryption, you need to decrypt stuff at some point)
- Yes, the question is when and how.
  You can enter it in the bootloader as a prerequisite to boot anything. You can also enter it at the display manager / login screen, which is a little further down the boot process.
  My desktop for example can boot up to the login screen and perform its NAS and routing duties all on its own. But my user and all of my user's data is still locked at that point: the computer is usable by guests and everything but even if you manage to throw a root exploit at it, my data is completely safe. Only when I log in, either locally or remotely, my password will go through PAM which will run a script that uses my password to unlock my home directory and mount it as I'm logging in.
  What changes is what is covered by the encryption, and when the key is required. My root is auto unlocked via TPM, my home is unlocked on demand as I log in to my user account.
  OP's problem is they have full disk encryption so they need the password to boot up Linux at all, but they also get a second password prompt to log in when it reaches the display manager, even if it's the same password. The solution is either they configure it to auto login since you need a password for the whole OS anyway, or they automate the unlocking of the root partition and use their login password to further decrypt the home directory (or rely entirely on the system being secure that the user isn't encrypted further and it's just a password prompt, which is what I think Windows does).

EDIT: Based on the responses I have to assume some of you guys live in windowless underground bunkers sealed off with concrete. Normal people don't need perfect encryption they just want to add an extra hurdle or two for the crackhead who steals the PC. I assumed Linux had a system similar to what Windows or MacOS has been doing for a decade but I am apparently wrong.

I am sorry you were treated like this and downvoted for just asking for help without being a jerk at all.

I was kinda annoyed at double password login when I setup my system too. So what I did was just enable automatic login for my user since I’m the only one. I just treat my disk password as my login form so I just enter one password. I still have a user password for things like sudo and other permissions handling when I’m logged in but getting into a new session is automatic on startup so it doesn’t annoy me anymore. Would that work for you?

That's exactly what I do lol.
I think this is what I might have to do as I really don't want to go back to Windows. I don't suppose if you know if there is a way to lock the drive upon logging out? Or do I need to do a full shutdown every time.
- Move your swap to encrypted part of your drive and suspend to disk. ;)
- I’m not sure LUKs can lock a drive that’s booted already since it’s not a RAM session like a live CD is and relies on the decrypted files to operate. This is why the encryption key is prompted from your boot manager prior to actually getting the system running. That said, I lock my computer all the time and just rely on the normal user password to get back in.
- IIRC and I may be wrong here the drive stays encrypted in sleep. Decryption is done in real time via your CPU. However the encryption key is stored in unencrypted RAM. Which is why the other comment suggests encrypting swap and hibernating, this writes RAM to disk.
I was kinda annoyed at double password login
Same. Not at all interesting.
Boot up password -> ATA DriveLock password -> LUKS FDE password -> Login password, that's where it's at.
/j
It's just funny situation if you forget the DriveLock master password. Yes, it has 2 passwords. The master password is needed to remove the user password which is used for unlocking. If you forget the master password, you can't ever reset the user password. If you forget both, you upgraded the drive to a paperweight. Additionally, some BIOSes may do hidden key derivation, store the master password in TPM, or do some other crap, so it's generally not recommended unless you actually need it.
This can also be set in hdparm.
Also, I have no idea what way there is for NVME drives, as this uses ATA commands. It's also good to note that some drives use this for hardware-based encryption, and some don't. So it brings varying security.
- If you forget both, you upgraded the drive to a paperweight.
  That's why I have a password manager on my phone.

Assuming you want:

Single password prompt instead of auto-decrypt with tpm
User's files to be encrypted

There are several ways to achieve this:

autologin (recommended for single user system): / is encrypted using luks or zfs native encryption and user's home needs to be unencrypted. User's password may be same as encryption password for convenience, though they still are two passwords used for different purposes.
pam mount: / is unencrypted or auto-decrypted and user's home is encrypted independently from / using zfs,luks,fscrypt,etc. In this case, user's login password must be same as user's home encryption password. It's suitable for multi-user system. NOTE: It cannot be used with autologin since user's home needs to be decrypted to log in.

WARNING: For tpm usage, using secure boot is highly recommended to prevent unauthorized user from accessing key stored in tpm.

To prevent auto-decrypt with tpm, tpm-pin can be used (with autologin for requirement #1).

systemd-cryptenroll with/without tpm: As far as I know it can be only used to unlock disk encrypted with luks2. It can be used without tpm with pkcs11-token (e.g. YubiKey) or fido2-device. It also uses parameter encryption while key is unsealed, so safe from key sniffing via communication bus. This is easy if secure boot is enabled and luks2 is used for encryption.
clevis with tpm: It can be used in place of systemd-cryptenroll. May be used with zfs native encryption. Though I'm not sure if it uses parameter encryption (correct me).
unencrypted keyfile on usb: Not sure about zfs, but you can use keyfile on a usb drive to decrypt luks containers.

NOTE: I'm not a forensic/security expert. I listed a brief overview of methods I could think of to keep user's files encrypted while providing single password till login.

Auto decrypt with TPM sounds fine to me but I have no idea what TPM is as this is my first PC with it.
Thanks for the great response though I'll look into these
- I have no idea what TPM is
  Read Skull giver's reply or look it up.
  Re-reading your post, I take you want to avoid typing long and tedious password? And that's why you want to auto-decrypt?
  (Recommended) You could use strong memorable passwords that are not difficult to type and enable autologin. Related xfcd comic:
  systemd-cryptenroll: For TPM usage, I highly recommend using secure boot. Though not sure if you can easily do that. A less secure alternative using systemd-cryptenroll would be use tpm2-pin and bind key to no pcrs (discouraged). But then you'll have to use luks2 for encryption. Notice from man systemd-cryptenroll regarding tpm2-pin:
  Note that incorrect PIN entry when unlocking increments the TPM dictionary attack lockout mechanism, and may lock out users for a prolonged time, depending on its configuration. The lockout mechanism is a global property of the TPM, systemd-cryptenroll does not control or configure the lockout mechanism. You may use tpm2-tss tools to inspect or configure the dictionary attack lockout, with tpm2_getcap(1) and tpm2_dictionarylockout(1) commands, respectively Also tpm2-pin is not disk encryption password and short alphanumeric password needed so tpm decrypts the device; so encryption password should be secured in a safe place. Also check if your distro supports systemd-cryptenroll.
  usb drive: read previous comment
  clevis: It probably isn't as simple as systemd-cryptenroll but I guess you can use zfs and combine that with tpm2-pin if not using secure boot (discouraged).
  You'll have to make a compromise somewhere between security and convenience. Even if you use pam mount, you'll have to enter the password, biometrics won't do.
  Edit: remove unnecessary user tag and add img uri
systemd-homed can also do it.
- oh, I forgot. Thanks for mentioning that :)

Afaik you can't. Disk encryption requires entering the password every time and it asks for it BEFORE the OS is started so you can't use biometric login either

That's not technically true as enabling bitlocker on windows and filevault on Mac don't require two different passwords.
- Mac will ask you to “log in” very early in the boot process to decrypt the disk, I assume it keeps the drive key encrypted with your password somewhere.
- Sorry idk much about Windows and Mac. But what you said sounds like their encryption systems aren't full disk encryption, they somehow found a way to store the password for login or they just disable the login password completely when the encryption is enabled
- I recently dug into this because I accidentally trashed my wife’s OS which was encrypted with bitlocker. PITA btw and I couldn’t beat the encryption
  Bitlocker encryption key hash is stored in 2 possible places. First is an unencrypted segment of the encrypted drive. This is bad because it’s pretty easy to read that hash and then decrypt the drive. The second place is on a Trusted Platform Module (TPM) which is a chip on the motherboard. This is better because it’s much more difficult to hack. It can be done but requires soldering on extra hardware to sniff the hash while the machine boots up. Might even be destructive… I’m not sure.
  Either way a motivated attacker can decrypt the drive if they have physical access. For my personal machines, I wouldn’t care about this level of scrutiny at all.
  Anyways you can see if any open source solutions support TPM.

I'm also a linux noob, but I thought having to unlock the encryption before getting to the actual account was part of the point. If the encryption is always already unlocked it's easier to break in.

Then how come Windows and MacOS don't require two different PWs?
- They give up some security by gaining convenience and slightly better UX.
  I can't vet Apple's security, but TPM isn't a silver bullet either.
  https://hacky.solutions/blog/2024/02/tpm-attack
- You keep bringing that up. Those are different systems with different approaches to security. You can compare them to death and back and it won't bring your system to where you want it.
  People have come to you with suggestions to achieve what you want and explained the consequences. Try that instead.

Instead of encrypting the entire drive, encrypt the home folder. That way it’s unlocked when you sign in.

Yes there is TPM for full disk encryption.

https://gist.github.com/orhun/02102b3af3acfdaf9a5a2164bea7c3d6#using-tpm-20

Do I had problem making swap partition work. As lockdown mode is triggered.

https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html

I current only encrypted home.

What it sounds like you want is only your home folder encrypted, where it decrypts seamlessly upon login. It sounds like you have encrypted OS root, which is more secure but necessarily requires a password before the system gets to the login screen.

Other than reinstalling your system, you do have the option of either making your decryption password shorter, and/or enabling auto-login after boot (if you're the computer's only user), so you'd only have to type one password instead of two.

Auto-Login makes the most sense I didn't consider that. I'll just have to be careful not to log out without shutting down.
I chose to use auto login for my PC. This way I'm only using my password to decrypt the drive after a reboot or the login screen after waking ffrom sleep.
Or you can do full disk encryption and store the encryption info in the TPM and lock it down against various PCRs such that changes to the boot order or firmware prevent the drive unlocking without a secondary decryption key, just like Windows and Macs do.
It’s a built in feature of systemd, among other tools.
- I'm not familiar with exactly what you mean, does it not require a password to boot that way? I have full-disk encryption on my laptop but not with TPM, grub just prompts me for a password before the kernel boots

If you want some more convenience but don't want to give up security, you can use hardware tokens like Nitrokey with GPG.

The process would be generate a random file using dd and /dev/urandom. Set this as the key for FDE. Encrypt it using your GPG and store it on /boot. Have a helper script to ask you plugin your Nitrokey and (optional) pin to decrypt the keyfile to have root decrypted. I had read this on some blog for dm-crypt so you will need to research and adopt to your setup.

Others have given you ways of doing this, with TPM or hacking away by using the same password and auto-login. Many have told you you shouldn't, but I think no one explained why.

When the bootloader chooses the OS that OS might be on an encrypted or an unencrypted disk. If the OS is on an unencrypted disk it can be easily hacked and then all bets are off. So the only safe option is if the OS is on an encrypted disk, however to do that you need to decrypt the disk to access it. Now there are two options, either you need to provide a key for decryption (it does not need to be a password, it can be a thumb drive or fingerprint) or it happens automatically. If it happens automatically it's the same as not having encryption.

Enter TPM, which is trying to safely automatically decrypt the disk by using hardware validation. However here's the problem, the only reason you need disk encryption is to prevent against your hardware being stolen. If your hardware was stolen and you don't have disk encryption people can simply read the data. If you have disk encryption they need to decrypt the disk first. However when you use TPM or anything similar the disk gets decrypted automatically, meaning that it's almost the same as not having encryption at all.

If a hacker got a hold of your unencrypted disk they can open it on a second OS and extract the data. If they got a hold of a fully encrypted disk they are more or less screwed. But if your computer unencrypted the disk on boot all they have to do now is access the disk from your OS. There are several ways of bypassing a login, brute force it, or create new users. Not to mention possible security issues that might give the attacker access to your entire system, which is already unencrypted. Yes, having some form of encryption, even if it unencrypts automatically is better than no encryption at all, but not by much. I would argue that if you care about the data not being accessed you shouldn't have it decrypt automatically, and if you don't mind it decrypting automatically then encryption might be overkill for you.

If it’s LUKS encryption, yeah, you can unlock it with the TPM. I forget how. Basically you add another key to LUKS that comes from the TPM. There are guides online.

This reply isn't going to be helpful to OP, but thought I might add context for others passing by.

I'm using Arch Linux with LUKS encryption and gdm. As long as my user's password is the same as the LUKS password, I only ever type my password in once.

Just saying that a MacOS-like convenience is definitely possible on Linux.

Fascinating, you don't have automatic login enabled? And I assume this is at the pre-login prompt?
- Oof - forgot to mention that I do have autologin configured on gdm 😀

Thats how encryption works. Encryption with TPM protects against removing the drive and reading somewhere else, so I suppose it makes sense for most people.

Linux Distros have this option, Ubuntu has it now I think, but on the others its often manual setup.

Just search for "cryptsetup change to tpm"

If you want to do away with any protection you have with opting in to a security measure, like typing in a password, why don't you just reinstall and not select the encryption option?

Not requiring a password, or automatically entering a password to decrypt the filesystem, is essentially the same as not having encryption.

Decide which you want: Security or convenience. You cannot have both.

The common way to do it with LUKS2 and TPM as detailed on the Arch wiki. Not sure if that'll apply at all to ZFS and Zorin though

It is less secure though. What I do is set my computer to log in on start and I set up fingerprint auth. So I only need to login once on startup with the drive decryption.

Here's a reddit post on using clevis, TPM, and ZFS to decrypt.

You should also know that if you're mobo dies so does your data.

Dead motherboard is not an issue. LUKS supports multiple decryption key slots, you just set up the TPM as one of them. The fallback mode is you have you enter the password twice again.
- Ah, good to know.

You dont want to do that.

What's the point of encrypting something without a good passphrase? It defeats the whole purpose.

https://wiki.archlinux.org/title/Trusted_Platform_Module#Data-at-rest_encryption_with_LUKS

Thats what you want i think

Not sure if this works with drive encryption since it comes before the OS, but could this maybe be done with a YubiKey or something like that?

That way, you can plug it in and not worry about typing the password every time, but then it's also secure if someone takes your PC? As long as you remove the key when it's off of course.

Yes, systemd-cryptenroll supports Yubikey as well as generic FIDO2 tokens (and the TPM on most distros).

I use partial disk encryption myself using luksCrypt but without the auto unlock, your comment on the crackhead stealing it doesn't help you in that scenario, you 1000% can tie a partition encryption or home directory encryption and have it automatically decrypt using either a USB drive or TPM but, as is with Windows and MacOS if your PC gets stolen, the drive will be unlocked automatically regardless if it is you, it's only if the drive gets stolen on it's own that an auto unlock drive would help you, but it's not likely that only that will happen. At that point it might not be worth encrypting as a whole if that was your main concern.

My previous laptop got struck by lightning last month. Because I had a passphrase & not TPM for unlocking, I stripped the NVMe from the board, put it in an enclosure, entered the passphrase, & now I can access all my data for recovering from that situation. Had I tied it to TPM, I wouldn’t be able to recover my data (ZFS & Bcachefs only have one ‘slot’ for passphrases so no secondary, backup key)—while, as you pointed out, a thief can just boot the laptop they stole to get the data. Point being: passphrases offer advantages while being dead simple.
- shame it got struck by lightning, in another world you would've won the lottery with those chances

as others have pointed out, you can use systemd-cryptenroll to add your tpm as a way to unlock the disk at boot, security of this should be fine if secureboot is enabled (for this to work it will need to be anyway) and a password is set for the uefi. See the archwiki entry for setup info (command is as simple as systemd-cryptenroll --tpm2-device=auto /dev/rootdrive, also the device needs to be encrypted with luks2, no idea if zorin uses that by default but you can convert luks1 to luks2 {backup ur headers first!})

There used to be exactly what you are looking for. Encfs, and later ecryptfs could encrypt just the data in your home folder.

It was a checkbox in ubuntu installer, just like the full disk encryption today. The key was protected by the standard user password.

Unfortunately, it was deprecated due to discovered security weaknesses, and I'm not aware of any viable replacement.

Systemd-homed does the same. But it is quite a huge change in the system, see this thread on the Fedora Discuss
- Looks like it's creating a new volume in a file, but I don't see any type of quota being set upfront. If it scales up dynamically, it looks like a hot candidate. At this point I just hope distro maintainers settle down on something, anything, and give it a long term support.

Fedora has a good write up using Clevis, I am not sure how well Ubuntu supports it as they traditionally have been against using the TPM for security reasons. https://fedoramagazine.org/automatically-decrypt-your-disk-using-tpm2/

systemd-cryptenroll can do it very quick and easy, it’s literally about two minutes work, but Ubuntu patches out the TPM support.

Ubuntu will soon have TPM-backed full disk encryption as a standard option in the installer. Their implementation is designed to defeat most of the security implications that the naysayers bring up, except the login process is still a potential vulnerability. What you are asking about is not so far fetched as some of the comments would lead you to believe: https://ubuntu.com/blog/tpm-backed-full-disk-encryption-is-coming-to-ubuntu

I'm not familiar with zfs, but on an encrypred drive I got around this using crypt tab If i recall. you edit a crypt file, ftab points to it or something...sorry it was 7 years ago. But there is a way to make the OS grab the decryption password. You trade convienience for security obviously

I think people are misunderstanding the whole point of drive encryption. It's so that if the drive is stolen or lost, you don't have to worry about it as much. I personally don't see any benefit in doing this if I have to enter a password every time I plug the damn thing in. If you're concerned about somebody stealing your laptop or desktop, the disk-encryption should be the least of your worries.

To the OC; if you happen to use GNOME, then check out the settings in the DISKS app. It has auto-unlock options in the per-drive settings. I long ago configured it so my USB is auto-unlocked upon being plugged in. Though after several system resets and such whatever I did to do that seems to no longer be visible in the GUI, I know that's how I set it up in the first place.

To the OC; if you happen to use GNOME, then check out the settings in the DISKS app. It has auto-unlock options in the per-drive settings.
Thanks so much!
EDIT: This didn't work
- Is the setting missing? Or is the setting just not working properly? My laptop has the option greyed out and stuck in the "enabled" setting. I'm not sure how much help I'll be, but I can try?
They do understand the point. The problem is that if you use TPM to unlock on boot it is slightly self defeating. Now the attacker has access to your display manager or TTY. They can guess passwords, try to bypass the biometric checks, or find an exploit. But that does indicate a higher tech level that your average thief.
- I appreciate the concern but odds are if someone is stealing my PC its not going to be a 1337 hax0r. I am not keeping government docs on here I just don't want someone to be able to rip out the HDD and have easy access to everything.

I do not know the answer, but this got me thinking: would it be easier to set up a single login for both session and decryption if /home was on a separate partition and only /home was encrypted?

https://askubuntu.com/questions/1414617/configure-ubuntu-22-04-zfs-for-automatic-luks-unlock-on-boot-via-usb-drive

This is done via storing the unlock key in USB drive and need the USB plugged to auto unlock, see if it helps.

Linux, booting on zfs? Out of the box? What magic is this

@flork
Never set it up, but I think there's a PAM or systemd bit that allows for this. Something to look for is "headless server startup" or "drive unlock at boot". There is definitely a solution to this, as I had to forego setting it up on my Mac Mini server because there is no way to do it headless/remote.
Having to type in the unlock password at boot hasn't been a big hassle thus far on my ThinkPad running Fedora. Not bothered to setup a Yubikey or other tokens.

Good comment. Unfairly downvoted IMO