5 ms·
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
by subway 9y ago
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 9y agoSince, 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 9y agoLeveraging 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`
- ahnick 9y agoI 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.
- leni536 9y agoI 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.
- mabynogy 9y agoI see one at least. To use sshpass without a plaintext password.
- tyingq 9y agoIt'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.
- XorNot 9y agoWatching 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.
- arca_vorago 9y agoWhy would you use RSA, shouldn't everything that supports it use ed25519?
- beefhash 9y agoBecause the script in question uses openssl rsautl(1) and you can't really do encryption/decryption with Ed25519.
- cryptonector 9y agoBut 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).