similar to: Using Clevis/Tang (NBDE) to automatically decrypt volumes from within libguestfs

Hi, Has anybody managed to get network disk bound disk encryption to work with a non-root disk? It works fine for the root device, but the moment I add another volume to /etc/crypttab the system will no longer boot automatically. A tcpdump on the tang server shows no traffic while the system is stuck at the LUKS password prompt. The second encrypted volume is set up in the same way as the root

Radu Radutiu wrote: > On Tue, Nov 27, 2018 at 3:14 PM mark <m.roth at 5-cent.us> wrote: > >> What we do is to have the encryption key of the secondary filesystem in >> /etc/crypttab, which is, of course, 600. As it boots, it decrypts from >> that as it mounts the rest of the system. >> > Thanks, this is working as expected and it gave me the hint needed to

On Tue, Nov 27, 2018 at 3:14 PM mark <m.roth at 5-cent.us> wrote: > What we do is to have the encryption key of the secondary filesystem in > /etc/crypttab, which is, of course, 600. As it boots, it decrypts from > that as > it mounts the rest of the system. > > mark > Thanks, this is working as expected and it gave me the hint needed to find the actual

We've been required to encrypt h/ds, and so have been rolling that out over the last year or so. Thing is, you need to put in a password, of course, to boot the system. My manager found a way to allow us to reboot without being at the system's keyboard, a package called clevis. Works fine... except in a couple of very special cases. Those systems, the problem is that, due to older

On Fri, 8 Jun 2018, m.roth at 5-cent.us wrote: > We've been required to encrypt h/ds, and so have been rolling that out > over the last year or so. Thing is, you need to put in a password, of > course, to boot the system. My manager found a way to allow us to reboot > without being at the system's keyboard, a package called clevis. Works > fine... except in a couple of very

On 06/08/18 12:01, m.roth at 5-cent.us wrote: > Valeri Galtsev wrote: >> >> >> On 06/08/18 10:27, m.roth at 5-cent.us wrote: >>> John Hodrien wrote: >>>> On Fri, 8 Jun 2018, m.roth at 5-cent.us wrote: >>>> >>>>> We've been required to encrypt h/ds, and so have been rolling that out >>>>> over the last year or

On 06/08/18 10:27, m.roth at 5-cent.us wrote: > John Hodrien wrote: >> On Fri, 8 Jun 2018, m.roth at 5-cent.us wrote: >> >>> We've been required to encrypt h/ds, and so have been rolling that out >>> over the last year or so. Thing is, you need to put in a password, of >>> course, to boot the system. My manager found a way to allow us to reboot

Valeri Galtsev wrote: > > > On 06/08/18 10:27, m.roth at 5-cent.us wrote: >> John Hodrien wrote: >>> On Fri, 8 Jun 2018, m.roth at 5-cent.us wrote: >>> >>>> We've been required to encrypt h/ds, and so have been rolling that out >>>> over the last year or so. Thing is, you need to put in a password, of >>>> course, to boot the

Note that cryptsetup-reencrypt is a separate package on Fedora, but is already part of the appliance on Debian/Ubuntu. --- appliance/packagelist.in | 1 + daemon/luks.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++ generator/actions.ml | 18 ++++++++++++++++++ gobject/Makefile.inc | 2 ++ src/MAX_PROC_NR | 2 +- 5 files changed, 68 insertions(+), 1

John Hodrien wrote: > On Fri, 8 Jun 2018, m.roth at 5-cent.us wrote: > >> We've been required to encrypt h/ds, and so have been rolling that out >> over the last year or so. Thing is, you need to put in a password, of >> course, to boot the system. My manager found a way to allow us to reboot >> without being at the system's keyboard, a package called clevis.

Frank Cox wrote: >> > so if it would work, replace shortname with short and short1? > > With all of this hokey-pokey surrounding licensing and mac addresses, I > wonder if this outfit is actually still in compliance with the terms of > their license for this software, whatever it may be? > > If the software licensed to run only on Machine X and Machine X has now >

Valeri Galtsev wrote: > On 06/08/18 15:26, m.roth at 5-cent.us wrote: <SNIP> >>> On a similar note: one of the companies whose software scientists here >>> were using a lot (IDL is a product) changed hand several times, and >>> last owner changed licensing terms and stopped signing perpetual licenses. >>> With perpetual license you were able to keep

On 2018-06-08, Valeri Galtsev <galtsev at kicp.uchicago.edu> wrote: > > Frank, I 100% agree with you. The only case with spoofed MAC address and > license that may have chance to stand in court will be if all below are > true: > > 1. the company issued perpetual license. > 2. the company does not exist Based on what's written below, it seems like the company does

Valeri Galtsev wrote: > On 06/08/18 13:48, m.roth at 5-cent.us wrote: >> Frank Cox wrote: >>>>> so if it would work, replace shortname with short and short1? >>> >>> With all of this hokey-pokey surrounding licensing and mac addresses, I >>> wonder if this outfit is actually still in compliance with the terms of >>> their license for this

https://bugzilla.mindrot.org/show_bug.cgi?id=3553 Bug ID: 3553 Summary: PROTOCOL.key format specification is incorrect for encryption using AEAD transports Product: Portable OpenSSH Version: 9.3p1 Hardware: All OS: All Status: NEW Severity: normal Priority: P5

On 06/08/18 15:45, m.roth at 5-cent.us wrote: > Valeri Galtsev wrote: >> On 06/08/18 15:26, m.roth at 5-cent.us wrote: > <SNIP> >>>> On a similar note: one of the companies whose software scientists here >>>> were using a lot (IDL is a product) changed hand several times, and >>>> last owner changed licensing terms and stopped signing perpetual

> > so if it would work, replace shortname with short and short1? With all of this hokey-pokey surrounding licensing and mac addresses, I wonder if this outfit is actually still in compliance with the terms of their license for this software, whatever it may be? If the software licensed to run only on Machine X and Machine X has now been junked and replace by Machine Y, then isn't the

On 06/08/18 15:26, m.roth at 5-cent.us wrote: > Valeri Galtsev wrote: >> On 06/08/18 13:48, m.roth at 5-cent.us wrote: >>> Frank Cox wrote: >>>>>> so if it would work, replace shortname with short and short1? >>>> >>>> With all of this hokey-pokey surrounding licensing and mac addresses, I >>>> wonder if this outfit is

The reason I want to assign one IP to two MAC addresses is that I have one (and only one) user for whom I have to spoof the MAC address (it's a case of stupid software licensing). But... his system is encrypted. Now, we're using clevis to allow reboots without someone being at the keyboard to type in the password. Those of you who've looked at clevis see where this is going: clevis

hi, we have successfully implemented at tang/clevis environment for automatically entering luks keys and booting hosts without operator intervention. Now we would like to use this as well on ipv6 networks, but I do not seem to get it to work. I have already posted this issue to the dracut devs github issue tracker ( https://github.com/dracutdevs/dracut/issues/554) but no response so far. Maybe