Store and read SSH pvt keys from the vault

Dear Experts,

my company is evaluating some password vaults and we are currently running our evaluation on HashiCorp and we are trying to address the following use case:

A user is created in a generic Unix, but the same credentials could allow access to any other Unix box in the company.
We decided to implement a password less approach, where we would like to create for the user JDOE, through ssh-keygen, the pair pvt+pub key and store the pvt in the vault system and the public in each box.

To explain better: let’s suppose that we have 10 linux boxes, once the ssh-keygen will be executed, we are expecting to copy the id_rsa in HashiCorp and to propagate the file in all other 10 linux boxes in the .ssh directory.
At login time, the user will read the pvt key from the vault and will use it to do the authentication.

We saw that the ssh format is used with the OTP, that we don’t want to use (we would like to keep the same key for longer time), while we would be happier to do something simpler like
vault kv put secret/jdoe pvtkey="----BEGIN PRIV…" and so on.
We discovered that this cannot be done in this way, because the KV format is only dealing with single lines: do you have an advice about how we could store more complex formats, like a PVT key, without the need of using “one time”?
We are trying in this moment to run something like:
vault kv put myvault/certificates key=$(cat .ssh/id_rsa)

We wish to change periodically the key pairs, we are expecting to run every X of the month the ssh-keygen command, store back the pvt key to the vault using “vault patch”, and push to all unix boxes the new public key.

Thanks in advance!

This is a pretty close approximation of what you’re after but not exactly. You’re better off talking to Hashicorp sales and technical team about your requirements.

Hello Aram,

long story short, what we are trying to make is to make this operation:

vault kv put secret/vault private_key=“SECRET”

But instead of SECRET, to store a private key.

Is there not an option to do this without using the CA? We wish to use the CA in a 2nd step, Thanks!

Actually our case is even more similar to this:

With the difference that we might only use the vault to store a pre-generated key.

Sort of breaks the intent but okay if it works for you.

I got your point and actually you are right: you mean to let the system to create the pair, and push out the public key.
It’s far better, was not in the initial design, but it could be good.
Thanks for the hint, I’ll let you know if it works.

There is no problem with storing multi-line secrets within the Vault K/V secret engine (we have various TLS certificates in there).

Along with what @stuart-c said … you can store anything in a KV. If it’s not char based (even multi line), you can base64 encode the content and store that.

Hello Stuart and Aram,
I don’t find how this could be done: I saw how to echo a pvt.key and to store into the KV, but only the first line is stored.
I also tried to put into a variable and after to redirect the output to the kv, but also in this case is not working, only the first line is stored

Just to explain, I’ve the following file.key:
==== Begin ====
==== End =====

I run the following instruction using the kv2:
vault kv patch secret/kv key=$(cat file.key)
The result is
Failed to parse K=V data: invalid key/value pair “Begin”: format must be key=value

Of course, that file.key is just a test, but the format is similar to any cert/pvt-key/pub-key

That’s a bash issue, not vault.

$ vault kv put secret/t1 k="$(cat ~/.ssh/id_rsa)"
$ vault kv get secret/t1
= Secret Path =

======= Metadata =======
Key                Value
---                -----
created_time       2022-05-20T10:40:21.357097319Z
custom_metadata    <nil>
deletion_time      n/a
destroyed          false
version            1

== Data ==
Key    Value
---    -----
k      -----BEGIN RSA PRIVATE KEY-----
1 Like

Hello Aram, you were completely right, it’s working.
We are moving forward on our evaluation of the solution, we are quite happy so far.
Thanks for the support!