
Show HN: Use encrypted passwords in shell scripts signed with your SSH key - ahnick
https://github.com/ahnick/encpass.sh
======
tolmannator
I just use pass[0] from the command line.

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

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

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

[0] - [https://direnv.net](https://direnv.net)

~~~
tolmannator
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](https://nixos.org/nix/manual/#sec-nix-shell)

------
rockymadden
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](https://github.com/rockymadden/github-crypt)

~~~
ahnick
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?

~~~
rockymadden
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.

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

[https://github.com/blog/2503-deprecation-notice-removing-
ano...](https://github.com/blog/2503-deprecation-notice-removing-anonymous-
gist-creation)

------
viraptor
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](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.

~~~
georgyo
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.

~~~
schoen
> 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...](http://cs.wellesley.edu/~cs310/lectures/26_rsa_slides_handouts.pdf)

[https://crypto.stanford.edu/~dabo/papers/RSA-
survey.pdf](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...](https://en.wikipedia.org/wiki/Malleability_%28cryptography%29#Example_malleable_cryptosystems)

------
subway
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.

~~~
ahnick
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

~~~
subway
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`

~~~
leni536
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.

~~~
diggan
> 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?

~~~
leni536
Exactly.

------
howlett
I've made a very similar thing:
[https://www.remotepassword.com](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.

~~~
ahnick
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/](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.

------
brlewis
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.

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

~~~
Piskvorrr
. ./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"

~~~
ahnick
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.

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

~~~
ahnick
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.

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

~~~
ahnick
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.

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

~~~
ahnick
Is there a security benefit to using this?

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

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

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

~~~
ahnick
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?

~~~
ahnick
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](https://git.gnome.org/browse/libsecret/tree/tool).
So I guess it can be used anywhere that gnome is supported.

