On Friday, 15 July 2022 18:15:04 CEST Grant Taylor wrote: > On 7/15/22 1:15 AM, J. Roeleveld wrote: > > Yes. > > Okay. > > That simply means that SSH keys won't be used to authenticate to the > remote system. > > > How would it not prompt for a password. > > There is a PAM module; pam_ssh_agent_auth, which can be used to enable > users to authenticate to sudo using SSH keys. This means that the user > /does/ authenticate to sudo as necessary. It's just that the > authentication happens behind the scenes and they don't need to enter > their password. Thus you can avoid the NOPASSWD: option which means a > better security posture.
Hmm... interesting. I will look into this. But, it needs the agent to be running, which will make it tricky for automation. (I have some scripts that need to do things on different systems in a sequence for which this could help) > > I need something that will take the password from the vault (I > > can do this in Python and shell-scripting. Probably also in other > > scripts). Authenticating to the vault can be done on a session basis > > and shared. So locally, I'd only login once. > > Sure. > > > Currently, yes. I never physically see the password as it currently > > goes into the clipboard and gets wiped from there after a short time > > period. Enough time to paste it into the password-prompt. It's > > the copy/pasting that I am looking to automate into a single > > "login-to-remote-host" script. > > I would not consider the copy and paste method to be secure. There are > plenty of utilities to monitor the clipboard et al. and copy the new > contents in extremely short order. As such, users could arrange to > acquire copies of the password passing through the clipboard. I know, which is why I was investigating automating it. The passwords are too long to comfortably copy by hand. > I would strongly suggest exploring options that don't use the clipboard > and instead retrieve the password from the vault and inject it into the > remote system without using the clipboard. > > Or, authenticate to sudo a different way that doesn't involve a > password. This will work for 90+ percent of the use cases. Meaning > that the sensitive password is needed for 10 percent or less of the > time. Thereby reducing the possible sensitive password exposure. }:-) > > > I prefer not to use SSH keys for this as they tend to exist for years > > in my experience. And one unnoticed leak can open up a lot of systems. > > That is a valid concern. > > I'd strongly suggest that you research SSH /certificates/. SSH > /certificates/ support a finite life time /and/ can specify what > command(s) / action(s) they can be used for. > > My $EMPLOYER uses SSH /certificates/ that last about 8 hours. I've > heard of others that use SSH /certificates/ that last for a single digit > number of minutes or even seconds. The idea being that the SSH > /certificate/ only lasts just long enough for it to be used for it's > intended purpose and no longer. I will definitely investigate this. They sound interesting. I'd set the validity to a lot less if this can be automated easily. > The ability to specify the command; e.g. "su -" that is allowed to be > executed means that people can't use them to start any other command. }:-) > > > This is why I use passwords. (passwords are long random strings that > > are changed regularly) > > Fair enough. I only counter with take a few minutes to research SSH > /certificates/ and see if they are of any interest to you. Added to my research-list. -- Joost
