Securing your client

1

Good morning,

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,
Joe

2

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?

3

Good morning @simos. Yes, the primary password is required to unlock the client certificate.

1 Like
4

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.

5

Google suggests you do that with openssl rsa -aes256 -in your.key -out your.encrypted.key

6

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!

7

yeah, if that still works well enough, it’d be worth adding to the page that talks about authentication or maybe the security page.

8

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 :slight_smile:

9

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.

10

FWIW: doc: Hints on encrypting client key by PriceChild · Pull Request #468 · lxc/incus · GitHub

2 Likes
11

Another idea for securing your web connection - setup wireguard & have the web interface listen there (I do this with the REST port 8443)

12

Interesting tool. Thanks for sharing the link.

Why did you create a fork? Just curious.

13

The original 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 wg0
  • The other advantage with this approach is the firewalling for wireguard takes care of access to the internal service
3 Likes
14

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 step-certificates for postgresql client certificates in gitea (both run in separate Alpine LXD containers) - so the client certs should work ok with incus

I run most things in lxd / incus under Alpine - except where I need podman (which works better when systemd is available if using it for kubernetes inside LXD)

1 Like
15

It sounds like you might have a blog post or a tutorial in you. :smiley:

Another option would be a long thread. :thinking:

Thanks for sharing, I am learning a lot from your posts.

1 Like
16

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 :grinning:

If you’ve not seen it already - see also distrobuilder-menu for creating custom containers.

17

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.

18

Both should be done.

  • Another security idea - use KeepassXC to store the password secured with a hardware key like “OnlyKey” (like a Yubikey but protected by a PIN) - it is then safe to backup the database to the cloud (Storj is a good choice - as it’s also encrypted & you control the key)