Closed n-hass closed 7 months ago
Can I also make a suggestion that some refactoring take place? The same pattern is duplicated like ~5-6 times to build a process::Command with the ssh options etc. I think a factory-style function would be helpful here and would make the code significantly more readable.
I'm happy to do this in this PR or make another.
@n-hass
Thanks for your contribution!
I'm not sure how I feel about transmitting passwords for sudo. Generally, you should use ssh keys with attached permissions instead.
As for the refactoring, feel free to open another PR since it is not related to this one.
Agreed, keys are always safer. However, from a security perspective, I believe this technique is sound.
Functionally this is no different than SSH'ing as the non-root user and entering the sudo password interactively through the tty, as deploy-rs would pipe the password to the ssh session after the session has been opened. The password is never transmitted or stored plaintext (apart from when in-memory in deploy-rs).
I think some, myself included, are more comfortable with this than widening SSH permissions for root, or using a sudo pam / ssh-agent forwarding workaround.
Perhaps a warning/'disclaimer' could be included somewhere to encourage use of keys in a production environment?
Sorry, forgot to tag @PhilTaken . See above
Thanks @rvem! Is it okay if I squash?
Yeah, sure
Thanks!
This adds a prompt for entering the sudo password interactively, so that system deployments can be activated when using non-root sshUsers. Fixes #78.
I have chosen to handle this locally (in deploy) and pipe the password to stdin of the ssh session, rather than via psuedo-terminal as this is more reliable. This also means that magicRollback works, unlike the "-t" workaround.