![]() Try rebooting the system, and you’ll see the partition being mounted automatically. Following up on the example in the Appendix, with a keyfile stored on Azure Blob Storage, the script would look like this: The content of the script completely depends on how and where you stored your keyfile. You will need to create a script that can return the keyfile when invoked, stored as /etc/luks/key.sh Step 2: Create a script returning the keyfile You can see an example of doing this in the Appendix below. HTTPS servers, including object storage services such as AWS S3 or Azure Blob Storage make sure you’re using TLS to protect the data while in transit, rather than basic HTTPįor a simple (but effective enough) solution, you can store the keyfile in Azure Blob Storage.You can pick and choose any place you’d like some ideas include: You will then need to store the keyfile somewhere safe. I’m piping the encryption key through base64 so we don’t have to deal with binary files, making things more manageable. This should be 256-bit (32 bytes) long, and can be generated with:ĭd bs = 32 count = 1 if =/dev/random | base64 > keyfile The first thing we need to do is to generate a keyfile. Note: this approach can not be used with encrypted root volumes, but only with secondary disks. Turns out, there’s a relatively simple solution, which requires just two systemd units. in case of a reboot after a power outage)? In other words, how to have your cake and eat it too. How could I have the LUKS encryption key stored in a secure, remote place, while at the same time being able to have the encrypted disk automatically mounted without manual intervention (e.g. If someone were to steal the physical server (imagine this were a small Raspberry Pi!), they would have access to the data without any issue. ![]() This approach wasn’t acceptable to me: while the data would be encrypted at rest, the key to open the encrypted partition would also be sitting in the same place. There are plenty of articles on how to do that, but when it comes to automatically mounting the disk at boot, all of them recommend writing the encryption key in a keyfile and store it on the local filesystem. DS_Store files etc.( been building a simple NAS for my home, and I wanted to store the data on a secondary disk, encrypted with dm-crypt/LUKS. Also, better SMB optimization like, custom nf settings, the ability to choose to remove. Some areas of improvement I would love to see are, further customizing the mount points, by allowing us to set a custom mount point name which we would like to appear, for example, the path server/files/shared I would like to customize it more naming it S - Drive. (2) exporting setting to configuration profiles so that you can deploy the settings easily with Jamf Pro, and (3) other cool features like, custom mount points, run apps/scripts or open files on successful mount, and safely unmounting if the drive is unavailable.ĪutoMounter is not perfect, but its damn close. I understand that most of you already use login items and finder to achieve this or other tools like mountain duck and expandrive, but what sets this apart from the competition, this was written with the SysAdmin in mind.ĪutoMounter and its pro settings, go a little further then its competition by offering better customization by using (1) mount rules to auto mount the drive(s) if any or all the set rules were met, I searched Jamfnation a did not find much info about it, so I decided to share some info on it.ĪutoMounter by Pixeleyes LTD, allows you to manage your AFP/SMB/HTTPS/FTP shares and automount them on your mac. I hope this would be useful for someone other than me.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |