Laptop with two LUKS encrypted disks: HDD and SSD: How to start with same passphrase?
In my Linux laptop I've two disks:
One larger conventional HDD and a smaller but fast SSD.
On the SSD I've a small unencrypted /boot-Partition containung kernels, initrd images and GRUB. All remaining stuff (including the Linux /, swap, /home, ...) is in two LUKS encrypted pseudo devices. These are started at boot time using entries in /etc/crypttab. Everything works just fine.
But during booting I've to enter two passphrases to activate both LUKS container.
Since I've used the same pass phrase for both disks I'm now looking for a clever and secure way whichs allows me to start both disks by entering the passphrase only once during boot. Any ideas?
I already know that I could store the passphrase for the second disk in a keyfile on the already encrypted root filesystem on the SSD and refer to it in the /etc/crypttab file. But I fear this keyfile might leak somehow (possibly
it might show up in the initrd images on unencrypted /boot/ partition?).
linux encryption luks
edited Mar 20 '17 at 10:04
Community♦
1
asked Mar 23 '16 at 18:18
pefupefu
1307
add a comment |
In my Linux laptop I've two disks:
One larger conventional HDD and a smaller but fast SSD.
On the SSD I've a small unencrypted /boot-Partition containung kernels, initrd images and GRUB. All remaining stuff (including the Linux /, swap, /home, ...) is in two LUKS encrypted pseudo devices. These are started at boot time using entries in /etc/crypttab. Everything works just fine.
But during booting I've to enter two passphrases to activate both LUKS container.
Since I've used the same pass phrase for both disks I'm now looking for a clever and secure way whichs allows me to start both disks by entering the passphrase only once during boot. Any ideas?
I already know that I could store the passphrase for the second disk in a keyfile on the already encrypted root filesystem on the SSD and refer to it in the /etc/crypttab file. But I fear this keyfile might leak somehow (possibly
it might show up in the initrd images on unencrypted /boot/ partition?).
linux encryption luks
edited Mar 20 '17 at 10:04
Community♦
1
asked Mar 23 '16 at 18:18
pefupefu
1307
1
I don't suppose any initramfs generation utility (mkinitcpio, dracut...) would include/etc/crypttabto the initramfs, unless the user for some reason explicitly configure it to do so (but then that's a PEBKAC).
– Tom Yan
Mar 23 '16 at 18:49
That said, I would not be at all certain that crypttab would reread at precisely the correct point in the mounting process, and, of-course, if that file is compromised while the system is online, it can be used to recover the data later. (I don't have a solution to the OP question though - indeed its something I battled with as well)
– davidgo
Mar 23 '16 at 19:18
Today I found out that Michael Gebetsroither <michael@mgeb.org> has written a script for caching the passphrase. This script can be found here: github.com/gebi/keyctl_keyscript Unfortunately I was yet unable to get this to work on my Kubuntu 14.04 LTS laptop. May be I will spend some more time fiddling with it later.
– pefu
Mar 25 '16 at 16:33
add a comment |
In my Linux laptop I've two disks:
One larger conventional HDD and a smaller but fast SSD.
On the SSD I've a small unencrypted /boot-Partition containung kernels, initrd images and GRUB. All remaining stuff (including the Linux /, swap, /home, ...) is in two LUKS encrypted pseudo devices. These are started at boot time using entries in /etc/crypttab. Everything works just fine.
But during booting I've to enter two passphrases to activate both LUKS container.
Since I've used the same pass phrase for both disks I'm now looking for a clever and secure way whichs allows me to start both disks by entering the passphrase only once during boot. Any ideas?
I already know that I could store the passphrase for the second disk in a keyfile on the already encrypted root filesystem on the SSD and refer to it in the /etc/crypttab file. But I fear this keyfile might leak somehow (possibly
it might show up in the initrd images on unencrypted /boot/ partition?).
linux encryption luks
edited Mar 20 '17 at 10:04
Community♦
1
asked Mar 23 '16 at 18:18
pefupefu
1307
In my Linux laptop I've two disks:
One larger conventional HDD and a smaller but fast SSD.
On the SSD I've a small unencrypted /boot-Partition containung kernels, initrd images and GRUB. All remaining stuff (including the Linux /, swap, /home, ...) is in two LUKS encrypted pseudo devices. These are started at boot time using entries in /etc/crypttab. Everything works just fine.
But during booting I've to enter two passphrases to activate both LUKS container.
Since I've used the same pass phrase for both disks I'm now looking for a clever and secure way whichs allows me to start both disks by entering the passphrase only once during boot. Any ideas?
I already know that I could store the passphrase for the second disk in a keyfile on the already encrypted root filesystem on the SSD and refer to it in the /etc/crypttab file. But I fear this keyfile might leak somehow (possibly
it might show up in the initrd images on unencrypted /boot/ partition?).
linux encryption luks
linux encryption luks
edited Mar 20 '17 at 10:04
Community♦
1
asked Mar 23 '16 at 18:18
pefupefu
1307
edited Mar 20 '17 at 10:04
Community♦
1
asked Mar 23 '16 at 18:18
pefupefu
1307
edited Mar 20 '17 at 10:04
Community♦
1
edited Mar 20 '17 at 10:04
Community♦
1
edited Mar 20 '17 at 10:04
Community♦
1
1
asked Mar 23 '16 at 18:18
pefupefu
1307
asked Mar 23 '16 at 18:18
pefupefu
1307
asked Mar 23 '16 at 18:18
pefupefu
1307
1307
1
I don't suppose any initramfs generation utility (mkinitcpio, dracut...) would include/etc/crypttabto the initramfs, unless the user for some reason explicitly configure it to do so (but then that's a PEBKAC).
– Tom Yan
Mar 23 '16 at 18:49
That said, I would not be at all certain that crypttab would reread at precisely the correct point in the mounting process, and, of-course, if that file is compromised while the system is online, it can be used to recover the data later. (I don't have a solution to the OP question though - indeed its something I battled with as well)
– davidgo
Mar 23 '16 at 19:18
Today I found out that Michael Gebetsroither <michael@mgeb.org> has written a script for caching the passphrase. This script can be found here: github.com/gebi/keyctl_keyscript Unfortunately I was yet unable to get this to work on my Kubuntu 14.04 LTS laptop. May be I will spend some more time fiddling with it later.
– pefu
Mar 25 '16 at 16:33
add a comment |
1
I don't suppose any initramfs generation utility (mkinitcpio, dracut...) would include/etc/crypttabto the initramfs, unless the user for some reason explicitly configure it to do so (but then that's a PEBKAC).
– Tom Yan
Mar 23 '16 at 18:49
That said, I would not be at all certain that crypttab would reread at precisely the correct point in the mounting process, and, of-course, if that file is compromised while the system is online, it can be used to recover the data later. (I don't have a solution to the OP question though - indeed its something I battled with as well)
– davidgo
Mar 23 '16 at 19:18
Today I found out that Michael Gebetsroither <michael@mgeb.org> has written a script for caching the passphrase. This script can be found here: github.com/gebi/keyctl_keyscript Unfortunately I was yet unable to get this to work on my Kubuntu 14.04 LTS laptop. May be I will spend some more time fiddling with it later.
– pefu
Mar 25 '16 at 16:33
1
1
I don't suppose any initramfs generation utility (mkinitcpio, dracut...) would include
/etc/crypttab to the initramfs, unless the user for some reason explicitly configure it to do so (but then that's a PEBKAC).– Tom Yan
Mar 23 '16 at 18:49
I don't suppose any initramfs generation utility (mkinitcpio, dracut...) would include
/etc/crypttab to the initramfs, unless the user for some reason explicitly configure it to do so (but then that's a PEBKAC).– Tom Yan
Mar 23 '16 at 18:49
That said, I would not be at all certain that crypttab would reread at precisely the correct point in the mounting process, and, of-course, if that file is compromised while the system is online, it can be used to recover the data later. (I don't have a solution to the OP question though - indeed its something I battled with as well)
– davidgo
Mar 23 '16 at 19:18
That said, I would not be at all certain that crypttab would reread at precisely the correct point in the mounting process, and, of-course, if that file is compromised while the system is online, it can be used to recover the data later. (I don't have a solution to the OP question though - indeed its something I battled with as well)
– davidgo
Mar 23 '16 at 19:18
Today I found out that Michael Gebetsroither <michael@mgeb.org> has written a script for caching the passphrase. This script can be found here: github.com/gebi/keyctl_keyscript Unfortunately I was yet unable to get this to work on my Kubuntu 14.04 LTS laptop. May be I will spend some more time fiddling with it later.
– pefu
Mar 25 '16 at 16:33
Today I found out that Michael Gebetsroither <michael@mgeb.org> has written a script for caching the passphrase. This script can be found here: github.com/gebi/keyctl_keyscript Unfortunately I was yet unable to get this to work on my Kubuntu 14.04 LTS laptop. May be I will spend some more time fiddling with it later.
– pefu
Mar 25 '16 at 16:33
add a comment |
1 Answer
1
active
oldest
votes
That's not exactly the info you are looking for but if you store the passphrase for the second disk in a keyfile on the already encrypted root filesystem on the SSD and refer to it in the /etc/crypttab file this info might help: I just checked and the key isn't present on the initrd file. AFAIK, it's only securely stored in the encrypted root filesystem so this option might be a secure one after all.
answered Dec 31 '18 at 14:15
RseveroRsevero
112
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1056546%2flaptop-with-two-luks-encrypted-disks-hdd-and-ssd-how-to-start-with-same-passph%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
That's not exactly the info you are looking for but if you store the passphrase for the second disk in a keyfile on the already encrypted root filesystem on the SSD and refer to it in the /etc/crypttab file this info might help: I just checked and the key isn't present on the initrd file. AFAIK, it's only securely stored in the encrypted root filesystem so this option might be a secure one after all.
answered Dec 31 '18 at 14:15
RseveroRsevero
112
add a comment |
That's not exactly the info you are looking for but if you store the passphrase for the second disk in a keyfile on the already encrypted root filesystem on the SSD and refer to it in the /etc/crypttab file this info might help: I just checked and the key isn't present on the initrd file. AFAIK, it's only securely stored in the encrypted root filesystem so this option might be a secure one after all.
answered Dec 31 '18 at 14:15
RseveroRsevero
112
add a comment |
That's not exactly the info you are looking for but if you store the passphrase for the second disk in a keyfile on the already encrypted root filesystem on the SSD and refer to it in the /etc/crypttab file this info might help: I just checked and the key isn't present on the initrd file. AFAIK, it's only securely stored in the encrypted root filesystem so this option might be a secure one after all.
answered Dec 31 '18 at 14:15
RseveroRsevero
112
That's not exactly the info you are looking for but if you store the passphrase for the second disk in a keyfile on the already encrypted root filesystem on the SSD and refer to it in the /etc/crypttab file this info might help: I just checked and the key isn't present on the initrd file. AFAIK, it's only securely stored in the encrypted root filesystem so this option might be a secure one after all.
answered Dec 31 '18 at 14:15
RseveroRsevero
112
answered Dec 31 '18 at 14:15
RseveroRsevero
112
answered Dec 31 '18 at 14:15
RseveroRsevero
112
answered Dec 31 '18 at 14:15
RseveroRsevero
112
112
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1056546%2flaptop-with-two-luks-encrypted-disks-hdd-and-ssd-how-to-start-with-same-passph%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
I don't suppose any initramfs generation utility (mkinitcpio, dracut...) would include
/etc/crypttabto the initramfs, unless the user for some reason explicitly configure it to do so (but then that's a PEBKAC).– Tom Yan
Mar 23 '16 at 18:49
That said, I would not be at all certain that crypttab would reread at precisely the correct point in the mounting process, and, of-course, if that file is compromised while the system is online, it can be used to recover the data later. (I don't have a solution to the OP question though - indeed its something I battled with as well)
– davidgo
Mar 23 '16 at 19:18
Today I found out that Michael Gebetsroither <michael@mgeb.org> has written a script for caching the passphrase. This script can be found here: github.com/gebi/keyctl_keyscript Unfortunately I was yet unable to get this to work on my Kubuntu 14.04 LTS laptop. May be I will spend some more time fiddling with it later.
– pefu
Mar 25 '16 at 16:33