>Generally, you could use your own storage scheme (e.g. an encrypted >file that's decrypted with a password entered on the console) and load >the secrets into the daemon via VICI protocol.
Can swanctl ask interactively for the password if not inserted in the conf file? > If you store them in swanctl.conf (or a file included by it) make sure > it's only readable by the appropriate user (root or whatever swanctl > will be run as). Does this guide apply to swanctl too? Cause currently I'm root-only https://wiki.strongswan.org/projects/strongswan/wiki/ReducedPrivileges ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Il lunedì 13 maggio 2019 12:33, Tobias Brunner <[email protected]> ha scritto: > Hi, > > > 1. Is there a "more secure" way to store the per-user psk password in > > swanctl.conf file? > > First, note that shared keys will be accessible in memory once loaded > into the daemon via VICI. So the question is whether you are concerned > with the actual storage, or with other attack vectors. > > Generally, you could use your own storage scheme (e.g. an encrypted file > that's decrypted with a password entered on the console) and load the > secrets into the daemon via VICI protocol. > > Then the available options depend on the type of secret. IKE pre-shared > keys must be available to the daemon locally. However, EAP secrets may > be verified via RADIUS and stored on a different host (they still have > to be available in plaintext to the RADIUS daemon there). If EAP-GTC is > an option (many clients don't support it), the passwords may be verified > via PAM and stored in hashed form. And for EAP-MSCHAPv2, passwords may > be stored as MD4/NT-hashes in swanctl.conf. > > If you store them in swanctl.conf (or a file included by it) make sure > it's only readable by the appropriate user (root or whatever swanctl > will be run as). > > > "It is not recommended to define any private key decryption passphrases, as > > then there is no real security benefit in having encrypted keys. Either > > store the key unencrypted or enter the keys manually when loading > > credentials." > > Maybe I'm misreading that sentence. I just have the plain password. > > That paragraph is referring to passwords used to encrypt private keys, > not shared secrets. > > > 2. In the pools section, is there a way to define the default > > localdomain-search variable? > > If you know the numeric identifier, you can use that to assign arbitrary > configuration attributes to clients (they will just ignore it if they > don't know/support it). There is no IKEv2 attribute type standardized > for the search domain, though. > > Regards, > Tobias
