Password based sudo

[blaggacao]

After bootstrapping a host with regular nixos-install and setting a password for nixos user, I then tried to deploy subsequent generations with deploy-rs. However, even if I turned on interactive mode, I was not able to enter the sudo password.

Either I didn't understand how to do it (ux problem) or it is plain not possible at the moment (i think this is the case).

Some people might be reluctant to configure passwordless sudo as base line, hence a way is needed to supply elevation credentials during deployment.

Coming from divnix/digga#197 (comment)

[notgne2]

{
	sshOpts = [ "-t" ];
}

Related is #36 which aimed to solve this too

Interactive mode is an internal concept, allowing you to review the deployment before it's made, it has no effect on internal mechanics otherwise (though maybe it would make sense to set -t by default when interactive mode is being used)

[kristoff3r]

Using sshOpts = [ "-t" ] doesn't work for me:

-> % nix run github:serokell/deploy-rs -- -s
🚀 ℹ️ [deploy] [INFO] Evaluating flake in .
🚀 ℹ️ [deploy] [INFO] The following profiles are going to be deployed:
[nuxbox.system]
user = "root"
ssh_user = "kris"
path = "/nix/store/j1k6xv2gzlwfd3f4hwy8n91503r4c3ds-activatable-nixos-system-nuxbox-21.05.20210419.0a5f5ba"
hostname = "nuxbox"
ssh_opts = ["-t"]

🚀 ℹ️ [deploy] [INFO] Building profile `system` for node `nuxbox`
Pseudo-terminal will not be allocated because stdin is not a terminal.
🚀 ℹ️ [deploy] [INFO] Activating profile `system` for node `nuxbox`
🚀 ℹ️ [deploy] [INFO] Creating activation waiter
[sudo] password for kris: [sudo] password for kris: 
                                                    Sorry, try again.
                                                                     [sudo] password for kris: 

The last 2 lines appear after I try to enter my password, but it is always denied. Based on the mangled indentation I guess the terminal is in a bad state due to the nix build logging? I've tried with bash instead of zsh and with -tt instead of -t, both without success.

[Shados]

@notgne2 even with sshOpts = [ "-t" ];, this is broken for me in precisely the same way it is broken for @kristoff3r.

[notgne2]

Not sure the cause of it but that's definitely a bug, I was almost certain I tested this at one point and saw that -t (or maybe it was -tt) worked in lieu of any other deploy-rs support for it, but I may be wrong or there may be a regression, I still don't think I plan to add any other support for it but at the very least I want it to work in this way, I'll look into it

[plabadens]

Hmm, having the exact same issue. Neither sshOpts = [ "-t" ]; nor sshOpts = [ "-tt" ]; seems to have any effect on the outcome.

[brprice]

Strangely, I find that deploy --dry-activate with sshOpts = [ "-t" ] works fine with password based sudo, but a full deploy has the same problem as above. I wonder how these code paths differ?

[brprice]

I know of two ways to avoid this issue whilst still having requiring authentication for sudo.

---

One way to work around this issue, at the cost of X11 forwarding, by moving the password prompt out of the terminal. I do not understand what (if any) the security implications are here. This is similar to #107. Running deploy-rs on NixOS, the following graphical prompts are available in nixpkgs:

• Unfortunately there is some race condition with x11_ssh_askpass where we spawn multiple graphical prompts at once, and they fight over grabbing the keyboard. If you type your sudo password quickly enough it can work, but normally one of them times out and that sudo attempt fails, leading to a failing deploy.
• I have better luck with ssh-askpass-fullscreen (unless, bizarrely, I am deploying to a qemu virtual machine, which is running (graphically) in the same desktop, then it locks up my wm, for some reason).
• lxqt.lxqt-openssh-askpass seems to work for me
• ksshaskpass also works for me, but is heavier-weight.

The setup is:
In the deployed profile

environment.etc."sudo.conf" = {
    mode = "0400";
    # uncomment one of the following lines
    #text = "Path askpass ${askpass}";
    #text = "Path askpass ${pkgs.x11_ssh_askpass}/libexec/x11-ssh-askpass";
    #text = "Path askpass ${pkgs.ssh-askpass-fullscreen}/bin/ssh-askpass-fullscreen";
    text = "Path askpass ${pkgs.lxqt.lxqt-openssh-askpass}/bin/lxqt-openssh-askpass";
    #text = "Path askpass ${pkgs.ksshaskpass}/bin/ksshaskpass";
  };
  services.openssh.forwardX11=true; # The server must allow X11 forwarding

In the deploy-rs options: sshOpts = [ "-X" ];

---

Another approach is to allow sudo authentication based on ssh key. This is not "password based sudo" anymore, but it isn't "non-authenticated sudo" ("passwordless") either.
This requires ssh keys to be set up, and an ssh-agent connection forwarded. I don't know the security implications of this either.
In the deployed profile, set security.pam.enableSSHAgentAuth = true;, and add sshOpts = [ "-A" ]; to the deploy-rs options. The deploy will need to be done in a context where an ssh agent is present.

---

Note that both these have chicken and egg problems: they need some options set on the server before deploy-rs can work.

[MagicRB]

its not a race condition running with RUST_LOG=trace reveals

🚀 ℹ️ [deploy] [INFO] Activating profile `system` for node `blowhole`
🚀 ❓ [deploy] [DEBUG] Constructed activation command: sudo -u root /nix/store/p5ramjvc4v9f10i31bz519cr5dmrlqpa-activatable-nixos-system-blowhole-22.05.20211206.bc5d683/activate-rs activate '/nix/store/p5ramjvc4v9f10i31bz519cr5dmrlqpa-activatable-nixos-system-blowhole-22.05.20211206.bc5d683' '/nix/var/nix/profiles/system' --temp-path '/tmp' --confirm-timeout 30 --magic-rollback --auto-rollback
🚀 ❓ [deploy] [DEBUG] Constructed wait command: sudo -u root /nix/store/p5ramjvc4v9f10i31bz519cr5dmrlqpa-activatable-nixos-system-blowhole-22.05.20211206.bc5d683/activate-rs wait '/nix/store/p5ramjvc4v9f10i31bz519cr5dmrlqpa-activatable-nixos-system-blowhole-22.05.20211206.bc5d683' --temp-path '/tmp'
🚀 ℹ️ [deploy] [INFO] Creating activation waiter

I'm really not sure how to tackle this as this is not a bug but a design choice afaik.

EDIT: WORKAROUND: disable magic rollback which is very unfortunate but it works

[jicksaw]

🚀 ℹ️ [deploy] [INFO] Creating activation waiter
[sudo] password for kris: [sudo] password for kris: 
                                                    Sorry, try again.
                                                                     [sudo] password for kris: 

The last 2 lines appear after I try to enter my password, but it is always denied. Based on the mangled indentation I guess the terminal is in a bad state due to the nix build logging? I've tried with bash instead of zsh and with -tt instead of -t, both without success.

I'm getting the same result with sshOpts = [ "-t" ];. It accepts the password if I enter every characters twice e.g. h-h-u-u-n-n-t-t-e-e-r-r-<ret>-<ret> for hunter2.

It asks the the pasword later again and this time every other character is echoed. The deploy succeeds, but the terminal is left mangled.

🚀 ℹ [deploy] [INFO] Deployment confirmed.

                                          ~/src/infra took 39s
                                                               ❯
~/src/infra
            ❯

[teto]

-t displays the promput but even with @jicksaw 's technique I could not make it work.

I then noticed the comment :

EDIT: WORKAROUND: disable magic rollback which is very unfortunate but it works

which worked for me !

[arjan-s]

Sadly this bug is still happening, but the workaround is still working as well! Too bad we can't use magic rollback, but at least deploy-rs is working now.

[jmatsushita]

For those who are looking for how to do this after the #257 fix:

deploy.nodes.myNode = {
  interactiveSudo = true;
}

No need for sshOpts = [ "-t" ]; or disablling magicRollback anymore 🥳