• 0 Posts
  • 102 Comments
Joined 1 year ago
cake
Cake day: July 9th, 2023

help-circle


  • notabot@lemm.eetoLinux@lemmy.mlVPS encryption
    link
    fedilink
    arrow-up
    16
    ·
    4 days ago

    It depends what you want to do with it. If it’s just for storing files/backups then encrypt them before uploading and make sure the key never goes anywhere near the VPS. If it’s for serving up something like a simple website, you probably care more about data integrity than exfiltration, so make sure you have the security, including selinux or equivalent, locked down, and regularly run integrity checks. If it’s for running something interactive, or where data will be generated or downloaded to the machine, you’re out of luck, there’s no even theoretical way of securing that against an adversary with that much access.


  • notabot@lemm.eeto196@lemmy.blahaj.zonetrout rule
    link
    fedilink
    arrow-up
    89
    ·
    11 days ago

    Wait, it purged the entire ecosystem except trout, so what are the trout eating? Don’t tell me we now have nuclear powered fish, the implications are terrifying. What happens if you’re bitten by a radioactive trout? Do we get troutman, the superhero we neither want, need or deserve?



  • It’s a non-starter for me because I sync my notes, and sometimes a subset of my notes, to multiple devices and multiple programs. For instance, I might use Obsidian, Vim and tasks.md to access the same repository, with all the documents synced between my desktop and server, and a subset synced to my phone. I also have various scripts to capture data from other sources and write it out as markdown files. Trying to sync all of this to a database that is then further synced around seems overly complicated to say the least, and would basically just be using Trillium as a file store, which I’ve already got.

    I’ve also be burnt by various export/import systems either losing information or storing it in a incompatible way.




  • It’s been years since I had to admin Windows servers, but I was quite impressed with the number of MS products where the install and configuration tools would output the Powershell commands to carry out the changes you’d asked for. It made it quite a lot easier to automate. I’d love to see that paradigm catch on more widely, with the GUI and CLI having the same functionality and the GUI giving you the commands to run.





  • I’ve found HSBC to be ok using Firefox on Linux. I don’t know if they have integrations with any accounting software, but the web access works well, and you can export your transactions for processing locally.

    ETA: I’ve run small business accounting on Gnucash, I found the learning curve a bit steep, but once you ‘get it’ it’s handy.


  • Sorry for the slow reply, life occurred.

    I think I understand where you’re coming from with the desired to be productive and not reinstall. I think I’ve been there too! One thing that I can suggest, if you do have the time, is to learn a system like Ansible and use it to setup and configure your machine. The discipline of keeping all of the config as source rather than making ad-hoc changes reduces the chance of thinking you’ll make just one little change and breaking something, and, if something does go wrong, you can get back to your working configuration quickly.

    Bearing in mind that there really isn’t anything you can do to stop yourself if you’re really determined to not lose the data, because if you can read it at any time you can back it up, the closest you are likely to come is something like creating new key with GPG then using the TPM to wrap your secret key and deleting the original. That way the key is only usable on that specific machine. Then use the key-pair to encrypt your ‘guard’ files. You can still decrypt them because you have the wrapped secret keys and you’re on the same machine, but if you wipe the drive and lose those keys the data is gone. The TPM wrapping prevents you from taking the keys to a different machine to decrypt your data.

    There’s an article with some examples here,

    Having said all of that, this still doesn’t help if you just clone the disk as all of the data, including the wrapped key and the encrypted files will be cloned. The one difference there is that the serial number of the hard drive will be different. Maybe you could use that, combined with a passphrase as the passphrase for your GPG key, but we’re getting into pretty esoteric territory here. So you could generate a secret key with a command like:

    ( lsblk -dno SERIAL /dev/sdb ; zenity --title "Enter decrypt password" --password) | sha1sum | cut -c1-40
    

    Where /dev/sdb is the device your root partition is on. zenity is a handy utility for displaying dialogs, there are others available. In this use it just prompts for a passsword. We then concatenate the drive serial number from lsblk with the password you entered and hash the result. The hashing is really only a convenient way to mix the two without worrying about the newline lsblk spits out. Don’t record the result of this command, but use it to set the passphrase on your new GPG key. Wrapping the secret key in the manner the article above suggests is a nice extra step to make it harder to move the drive to another machine or mess around in that sort of way, but not strictly necessary as that wasn’t in the scope of your original question.

    Now you can encrypt your file with: gpg -e -r <your key name> <your file>'. That will produce an encrypted version of <your file>called<your file>.gpg. To decrypt the file you can get gpg` to use the hashing command from above to get the passphrase with something like:

    gpg -d --pinentry-mode=loopback --batch --passphrase-fd 3 <your file>.gpg 3< <( ( lsblk -dno SERIAL /dev/sdb ; zenity --title "Enter decrypt password" --password) | sha1sum | cut -c1-40 )
    

    Once you’ve tested that you can decrypt the file successfully you can remove the original, plaintext, file. Your data is now encrypted with a key that is secured with a passphrase made of a string you know and the serial number of your disk and optionally wrapped with a key from the TPM that is tied to your physical machine. If you change the disk or the machine the data is irretrievable (ignoring the caveats discussed above). I think that’s about as close to your original goal as you can get. It’s rough around the edges, and I’m not sure I’d trust my data to it, but I believe it’ll work. If you do something like this, please test it thoroughly, I can’t guarantee it!






  • Having consistent interface names on servers that have several is useful, but we already had that option. The interface names they generate are not only hard to remember, but not terribly useful as they’re based on things like which PCI slot they’re in, rather than what their purpose is. You want interface names like wan0 and DMZ, not enp0s2. Of course, you can set it up to use useful names, but it’s more complicated than it used to be, so while the systemd approach looks like a good idea on the surface, it’s actually a retrograde step.