Show HN: Use encrypted passwords in shell scripts signed with your SSH key | Hacker News Reader

Show HN: Use encrypted passwords in shell scripts signed with your SSH key

github.com

117 pointsahnick46 comments

Open articleView on HN

I just use pass[0] from the command line.

pass show whatever-key | password-hungry-command -

[0] - https://www.passwordstore.org/

I use pass in combination with direnv[0] to load secrets into project directories as environment variables.

[0] - https://direnv.net

I use a shell.nix[0] file for this.

That way I can install dependencies and all that too as well as vars and aliases.

[0] - https://nixos.org/nix/manual/#sec-nix-shell

I use pass too, but technically you just need gpg to do this exact same thing. pass, in this use case, is literally just a very thin wrapper to gpg + a file with your password in it.

I understand, but personally, if I'm already using the convenient wrapper that is pass for everything else, it simplifies my life to use it here too.

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.

Oh yes, I'm not trying to convince you to change. I'm merely pointing out that this technique is not exclusive to pass, but rather that it's easily done without pass too. pass is an amazing tool!

Don't forget `| head -n1`, as pass(1) files can contain whatever (TOTP secrets, usernames, URLs, etc.) and only the first line contains the password

Good point, but if you're retrieving a key file for example, you'd just dump the content. Pass's one key per newline isn't a hard rule.

I did something similar where you could send GitHubers encrypted messages only they could decrypt via their SSH public key that GitHub makes available: https://github.com/rockymadden/github-crypt

That's a cool idea. It would be neat to have some way of sending that to the githubber builtin to the tool. Maybe send an email to the githubber if they have an email published or maybe just post it to a gist that then you can send them the link to?

I love that idea! I think you could use the anonymous gist API. Have the tool output to stdout/pbcopy the gist URL that was created upon encrypt and similarly have it accept a gist URL to decrypt. Nothing to send on either side beyond the URL.

Unfortunately creation of automated gists via the API is soon to be deprecated.

https://github.com/blog/2503-deprecation-notice-removing-ano...

I've considered adding Github public key support to EnvKey[1]. Currently, when inviting a user, you need to send a token out of band in order to not trust our servers during the invite process. Using the Github public key could potentially eliminate this step.

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

It's like a reverse gpg-agent. But I trust gpg to provide SSH keys more than random script to use SSH keys to provide encryption.

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.

I understand the point you are trying to make, but a RSA key is a RSA key.

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.

> I understand the point you are trying to make, but a RSA key is a RSA key.

Not really. http://cs.wellesley.edu/~cs310/lectures/26_rsa_slides_handou...

https://crypto.stanford.edu/~dabo/papers/RSA-survey.pdf

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.

https://en.wikipedia.org/wiki/Malleability_%28cryptography%2...

What problem does this solve?

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.

Since, by default ssh private and public keys get stored in the .ssh folder under the user's home folder, then it is convenient to leverage the already existing keys rather than having to generate new keys. (Of course you can also use different keys as well if you would like) You just include the script in your existing scripts you have and it works.

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

Leveraging that existing key is a downright anti-feature though. You should try to minimize the scope controlled by any given key.

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`

I think this is a good idea, b/c as long as the permissions are set on the generated private key to only be readable by the user, then the same level of security would be provided as accessing the user's private ssh key. It would also be nicer in situations like remote servers where the private key is not available due to security reasons. The intention was in these situations to generate your own keys using SSH, but there's no reason to make the user go through that exercise. I will look at making the change. Thanks for the suggestion.

I couldn't agree more. I don't even use the default ssh key, I have separate keys for separate servers. Even separate keys for separate github repos.

> Even separate keys for separate github repos

How does that work? You have no keys in your account itself and use Deploy keys with write access?

Exactly.

I see one at least. To use sshpass without a plaintext password.

It's not much different from Hashicorp Vault or Cyberark, etc.

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.

Watching people at work struggle to realise what Hashicorp vault does and doesn't do is kind of hilarious.

Because somewhere in the hype they never really considered how you authenticate to it in the first place.

Why would you use RSA, shouldn't everything that supports it use ed25519?

Because the script in question uses openssl rsautl(1) and you can't really do encryption/decryption with Ed25519.

But you can encrypt with Curve25519: E(public, M) = let (ephemeral_private, ephemeral_public) = gen_random_25519(): let shared_key = Curve25519(public, ephemeral_private): return ephemeral_public || E_AES256GCM(shared_key, M).

I've made a very similar thing: https://www.remotepassword.com

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.

That's an interesting idea. Kind of a simpler HashiCorp Vault service offered as a SaaS. I guess you would also be competing somewhat with any cloud provider that offers secrets management, but they are probably going to be more expensive and not as focused on this use case. The closest thing I could find to this is https://secrethub.io/, but looks like they are in private beta still.

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.

This tool looks really easy to use. So easy that it's likely to be used by people who aren't very security-savvy. Of course it would be overkill to try to educate everybody about everything, but I think it would be prudent for the README to mention the risk of passwords showing up in ps output.

Can you provide an example of this? How would the password show up in ps output?

. ./encpass.sh

password=$(get_password)

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"

I see, so basically if you invoke another process from within the script you are using the decrypted password AND you pass the decrypted password to that process, then it would be visible to ps. That makes sense as you are passing the decrypted password as an argument to the other process. This is similar to doing something like...

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.

Echo is a builtin; you won't see that in the process list (not sure this method doesn't have a different weakness).

Yes, that's true. It would show up in your command history though. Even though it's probably not readable by anyone else except root, it's still probably not a good idea to have it persisted to disk.

If it's inside a script, it won't go into command history, either.

Yeah, I was just giving an example of passing it into a script. Similarly, if encpass.sh is included in whatever.sh script the password won't show up in ps.

You may want to use "openssl passwd -table" for reading password.

Is there a security benefit to using this?

No. It's just convenient, because it takes care of confirmation, prompts, and disabling echo.

Okay, thanks for the recommendation. It would certainly be simpler to maintain.

I use secret-tool in shell scripts and I open my keyring on login.

Is secret-tool a linux only program? Where is the source for it maintained? (I was having trouble finding it) Do you use this as your main password manager too? Any thoughts on how this compares to pass?

In response to myself, it looks like this is a gnome project and the source can be found here -> https://git.gnome.org/browse/libsecret/tree/tool. So I guess it can be used anywhere that gnome is supported.

Reply on news.ycombinator.com