#SYNCTHING LINUX HOW TO#
#SYNCTHING LINUX MANUAL#
#SYNCTHING LINUX PASSWORD#

'secure boot') the key on the local machine is used to decrypt the encrypted filesystem(s). Essentially it is a separate chip on the motherboard which stores private keys and under specific predefined circumstance (e.g.

#SYNCTHING LINUX PASSWORD#

How bitlocker makes that a bit more 'user friendly' (and avoids the need for the user to enter a password or provide a key at boot) is that it stores the private key in a TPM hardware module (which most modern hardware is equipped with). So as per most things security, any compromise towards ease of use, is generally a compromise on security. As I noted in my opening paragraph, if you wish to share the threat model you are trying to protect against and the circumstance you are delaing with, perhaps I can add more ideas?Īny encryption (including bitlocker) requires a private key and/or a password. FWIW I found the related Syncthing issue and Syncthing forum thread via a google for 'syncthing data encryption' - there are plenty of other hits. Re the last one, whilst that's beyond the scope of a 'normal' TurnKey user, if you wish to investigate that further and/or share your use case with other Syncthing users, then I'm sure that you'll find more discussion online. If you choose to go one of those ways, then it'd be great if you could document as you go and share with others as I'm sure it would be useful! :)

#SYNCTHING LINUX HOW TO#

If you keep in mind that TurnKey is Debian under the hood (v15.x = Debian 9/Stretch) you should find plenty of info for how to implement either of those via google. The first 2 are not directly related to Syncthing at all and are relatively generic Linux things. It's worth noting that there is a related Syncthing GH issue, with associated discussion in a Syncthing forum thread. That way the data on the server would always be encrypted, without ever any need for user intervention on the server. Really, the 'proper way' for this to be done would be if Syncthing always stored the data encrypted (and decrypted it client side on the fly). But it still needs either a password, or a keypair to decrypt the data. As opposed to LUKS, EncFS can be used by a non-root user to mount an encrypted directory. Having said that, it could be argued that if doing it outside boot, an easier way to go would be to use EncFS (or similar). AFAIK mounting LUKS encrypted volumes requires root privileges.

#SYNCTHING LINUX MANUAL#

So whilst the server itself could reboot without interaction, the Syncthing service couldn't be restarted without manual intervention. Encrypted directoryĪ variation of the above model would be to not auto mount the encrypted volume at boot time, but at start of the syncthing service. Thus making it unsuitable for anything but a local server where you can access the console at boot time. So user interaction via the console is required at boot time. This requires the user to input the password (to decrypt the volume) at boot time. Generally how that is managed, is that the encrypted volume is mounted at boot time. Many other distros allow you to configure this on install, but unfortunately, TurnKey doesn't. Under this model, your would have an encrypted volume that is mounted to the Syncthing data storage file location. There are 2 options that I can think of OTTOMH: Encrypted disk/volume (e.g.

the files need to be unencrypted when Syncthing has access to them). So that means to have your files encrypted on your Syncthing server, the encryption needs to be transparent to Syncthing (i.e. But in the meantime.ĪFAIK Syncthing itself can not cope with encrypted data (it's encrypts the traffic between Syncthing nodes/clients - but not on the disk). If you could share the threat model you are trying to protect against and where your server is running, I could possibly provide some more nuanced opinion.

Syncthing linux