pass show whatever-key | password-hungry-command -
 - https://www.passwordstore.org/
 - https://direnv.net
That way I can install dependencies and all that too as well as vars and aliases.
 - https://nixos.org/nix/manual/#sec-nix-shell
I could see going with less glue if there wasn't an expectation that pass be installed and configured on a system already. Those aren't my systems though. Either would work.
My only concern is that these might have a tendency to get out of date or not be managed securely, in which case it could be more trouble than it's worth.
1 - https://www.envkey.com
A random article with explanation: https://ryanlue.com/posts/2017-06-29-gpg-for-ssh-auth
Edit: Yeah, the quoting is missing. The password with backslashes, spaces or other interesting bits will fail.
The only benefit of gpg here is for things longer than a password. The script is encrypting the password directly with the RSA key. The performance and security will be weaker on things much longer than a password.
Not really. http://cs.wellesley.edu/~cs310/lectures/26_rsa_slides_handou...
Some of the vulnerable systems that have been attacked this way basically were built on the premise than an RSA key is an RSA key. But an RSA implementation that's secure for one purpose might not be secure for another purpose, for example with malleability.
I'm not sure I understand why you would re-use your default ssh public key rather than just generate a dedicated rsa key. Because this uses OpenSSL it won't work with an ssh keyring for passphrase or hardware token management, I'm not sure I understand what using a key in ~/.ssh brings to the table.
This is meant to be a simple solution to needing to store your password in plaintext within a shell script. For example, you might have shell scripts that you create for quick duties like downloading or uploading some asset from a server. Typically sysadmins or developers might just store this in plaintext. The problem is later on they may forget that they stored it in plaintext and the script gets passed around and now you have credentials leaking all over the place. Also, works well for crowded environments where shoulder surfers might be present
You already lean heavily on OpenSSL, so it doesn't make a lot of sense why you wouldn't just generate a dedicated key with a `openssl genrsa -out .spiffytool/private.pem`
How does that work? You have no keys in your account itself and use Deploy keys with write access?
Both are like locking your house key in a lock box that has a different key. PCI, Sarbanes Oxley, HIPPA, etc, created a whole new category of funny software.
Because somewhere in the hype they never really considered how you authenticate to it in the first place.
Works on both Windows and Linux but the passwords are stored online (GPG encrypted). The main idea was to be able to revoke a password if a machine has been compromised.
The only downside I can really see here is clients are dependent on remotepassword.com being secure. (which is inherent in any SaaS model) For example, if remotepassword.com was compromised then all passwords could be deleted rendering downstream scripts dependent on those secrets temporarily inoperable and of course someone could start logging the password inputs on the website.
watch whatever.sh --pass=$password & # I'm using encpass.sh - security is magic pixie dust, therefore password is secured!
ps f # oh look, there's "watch whatever.sh --pass=hunter2"
echo "password" | whatever.sh
To prevent this from happening the other process should just source encpass.sh directly. I think it is probably worth mentioning this in the README as I could see someone doing that inadvertently. Thanks for the example.