I run an incus server on my home network. I sometimes ssh in (with a private key with password)
Using the command line and incus-ui-canonical packages is very attractive but the client security posture worries me.
Is it sensible to add a client certificate to my day-to-day user on my laptop, whether cli or firefox?
A few alternatives I’ve considered are running a separate user on my laptop to sudo to. (which wouldn’t work well for the web ui) Or adding then deleting the certificates when I start/stop work on something. (which is annoying and I’ll forget)
I don’t expect to be targetted by anybody, but the difference between how this secret is handled (which effectively gives full root on the remote server and all of it’s containers) to ssh keys (with their optional password) worries me?
Thanks for any advice,
Firefox supports Primary passwords (previously called Master password) to require the user to type that password as soon as they open the browser, then enabling all login/passwords that are saved in the browser.
Can you check whether Primary passwords also include the access to the client certificate?
Good morning @simos. Yes, the primary password is required to unlock the client certificate.
You can also add a password to
~/.config/incus/client.key. I’ve not done it in a LONG time but I remember adding support for prompting for the key in the CLI.
Google suggests you do that with
openssl rsa -aes256 -in your.key -out your.encrypted.key
That would be awesome, I will have a play thank you!
If it works, maybe I’ll find somewhere useful to PR into the docs… or find an existing reference I’d missed!
yeah, if that still works well enough, it’d be worth adding to the page that talks about authentication or maybe the security page.
The obvious issue is that unless you enable the new keepalive mode (keepalive: 30 in the remote in config.yml), then every single call to
incus will cause the prompt which may get a bit annoying
It does work perfectly thank you @stgraber . I just had to use
openssl ec for my key type. That makes me feel happier about my setup.
Another idea for securing your web connection - setup
wireguard & have the web interface listen there (I do this with the
Interesting tool. Thanks for sharing the link.
Why did you create a fork? Just curious.
wg-meshconf has static keys only (& didn’t have any option to create
pre-shared keys) - I made a PR but it’s still not merged
- I’ve used my fork to create a mesh with
pre-shared keys from home to & between all my servers (so each host can contact each other securely)
- Admin ports for any service I bind to
- The other advantage with this approach is the firewalling for
wireguard takes care of access to the internal service
Another thing I find useful for non public services is step-certificates for running my own Certificate Authority.
Certs are auto generated every
30 days by default (like LetsEncrypt) - this period is also configurable.
- I added service supervision to
step-certificates in Alpine Linux so it runs nicely. I’ve been running it in an Alpine LXD container with no issues for 7 months
- Create your
CA & just import it into your browser so all your admin pages are trusted
- I also use
postgresql client certificates in
gitea (both run in separate Alpine LXD containers) - so the client certs should work ok with
I run most things in
incus under Alpine - except where I need
podman (which works better when
systemd is available if using it for kubernetes inside LXD)
It sounds like you might have a blog post or a tutorial in you.
Another option would be a long thread.
Thanks for sharing, I am learning a lot from your posts.
At the moment I’m working on an LXD cluster - am at the stage of figuring out the networking & configuring
bgp routing. Eventually I’ll have a website back up
If you’ve not seen it already - see also distrobuilder-menu for creating custom containers.
Thanks for the networking suggestions.
The original post is targetted at protecting my incus key for the same reason why we don’t store gpg or ssh keys unencrypted. Setting up network restrictions/wireguard doesn’t really deal with the same attack surface.