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.
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 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.
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.
--
Grant. . . .
unix || die
