Yeah, sops doesn't work like this. In my local testing when I just write the hash in cleartext it passes the flake check, but I'm not sure if it is secure enough
Yeah, sops doesn't work like this. In my local testing when I just write the hash in cleartext it passes the flake check, but I'm not sure if it is secure enough
@Ahtlon instead of using the users.users.<name>.hashedPassword use users.users.<name>.hashedPasswordFile which will work with sops :)
Btw reading the description of that option on search.nixos.org i found this:
If users.mutableUsers is false, you cannot change user passwords, they will always be set according to the password options.
maybe this is something we want to set - but iam not sure.
@Ahtlon instead of using the `users.users.<name>.hashedPassword` use `users.users.<name>.hashedPasswordFile` which will work with sops :)
Btw reading the description of that option on search.nixos.org i found this:
> If users.mutableUsers is false, you cannot change user passwords, they will always be set according to the password options.
maybe this is something we want to set - but iam not sure.
maybe i miss something here, but as far as i understand none of the hosts can decrypt the malobeo user secrets.yaml at all right now. In the .sops.yaml. only admin keys are added. Also when we add new sops secret files that do not belong to a single host we need to properly handle the dummy-secrets overwrite for them so than run-vm with the --dummy-secrets flag can take care of that as in 1f9d39b53d/machines/modules/host_builder.nix (L174)
If there are questions on how to do that just let me know :)
maybe i miss something here, but as far as i understand none of the hosts can decrypt the malobeo user secrets.yaml at all right now. In the .sops.yaml. only admin keys are added. Also when we add new sops secret files that do not belong to a single host we need to properly handle the dummy-secrets overwrite for them so than run-vm with the --dummy-secrets flag can take care of that as in https://git.dynamicdiscord.de/kalipso/infrastructure/src/commit/1f9d39b53d0450bacc28bc1bef905f7ff51af563/machines/modules/host_builder.nix#L174
If there are questions on how to do that just let me know :)
With default enable, this does nothing anymore... Should we disable the admin account on bakunin? The autoupdate script should still run to apply updates but we (and any attackers) could no longer change the system manually
With default enable, this does nothing anymore... Should we disable the admin account on bakunin? The autoupdate script should still run to apply updates but we (and any attackers) could no longer change the system manually
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
ahtlon
kalipso
I'm not sure if the sops thing works. Maybe the hash in cleartext is secure enough?
Fixes #77
Yeah, sops doesn't work like this. In my local testing when I just write the hash in cleartext it passes the flake check, but I'm not sure if it is secure enough
@Ahtlon instead of using the
users.users.<name>.hashedPassworduseusers.users.<name>.hashedPasswordFilewhich will work with sops :)Btw reading the description of that option on search.nixos.org i found this:
maybe this is something we want to set - but iam not sure.
Actually there is more to setting a userpw with sops: https://github.com/Mic92/sops-nix?tab=readme-ov-file#setting-a-users-password
Still doesn't work in run-vm. Probably because of the early-loading stuff
maybe i miss something here, but as far as i understand none of the hosts can decrypt the malobeo user secrets.yaml at all right now. In the .sops.yaml. only admin keys are added. Also when we add new sops secret files that do not belong to a single host we need to properly handle the dummy-secrets overwrite for them so than run-vm with the --dummy-secrets flag can take care of that as in
1f9d39b53d/machines/modules/host_builder.nix (L174)If there are questions on how to do that just let me know :)
Rebased on #84
e379679448to912c8e1195@@ -38,6 +37,8 @@ inethernetDrivers = ["r8169"];};malobeo.users.malobeo = true;With default enable, this does nothing anymore... Should we disable the admin account on bakunin? The autoupdate script should still run to apply updates but we (and any attackers) could no longer change the system manually
@@ -52,1 +52,4 @@malobeo.users = {malobeo = true;admin = true;Forgot to remove this when I changed the default, but it also doesn't hurt to write it explicitly
@@ -0,0 +23,4 @@description = "malobeo user, password and ssh access, no root";extraGroups = [ "pipewire" "pulse-access" "scanner" "lp" ];openssh.authorizedKeys.keys = sshKeys.admins;hashedPassword = "$y$j9T$39oJwpbFDeETiyi9TjZ/2.$olUdnIIABp5TQSOzoysuEsomn2XPyzwVlM91ZsEkIz1";Should be changed at some point to use sops