unauthenticated ssh engine public key text/plain response

[rjhornsby]

Describe the bug
The unauthenticated endpoint for retrieving the ssh engine CA public key returns text/plain, while typically vault responds to requests with a JSON object.

This breaks the unauthenticated vault read /path/to/ssh/public_key, but more importantly it breaks the same trying to render a template, presumably because the view/renderer is expecting JSON.

To Reproduce
Steps to reproduce the behavior:

1. Run vault read /ssh/public_key
2. See error below

CLI:

╰─± vault read /ssh/public_key
Error reading /ssh/public_key: invalid character 's' looking for beginning of value

template:

Feb 18 23:34:14 ip-172-20-20-40 vault[12298]: 2023-02-18T23:34:14.652Z [ERROR] runtime error encountered: error="template server: vault.read(/ssh/public_key): vault.read(/ssh/public_key): invalid character 's' looking for beginning of value"

The first part of the ssh key is is ssh-rsa - I believe where the message invalid character 's' is coming from.

Further, attempts to coerce the server into replying with JSON are ignored:

$ curl -vvvvv -H "Accept: application/json" https://my.vault.com:8200/v1/ssh/public_key
> GET /ssh/public_key HTTP/2
> Host: vault.sev1tech.com:8200
> User-Agent: curl/7.61.1
> Accept: application/json
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 200
< date: Sat, 18 Feb 2023 23:19:07 GMT
< content-type: text/plain

Expected behavior
Most likely one of these two things are expected to happen:

1. The endpoint should either honor an Accept: application/json header, outright return JSON instead of plain/text, or default to JSON but allow and honor a client's Accept: text/plain header.
2. The renderer/viewer honors the server's Content-Type header text/plain and handles it accordingly, rather than assuming the response is JSON and crashing/erroring.

Environment:

• Vault Server Version: 1.12.2
• Vault CLI Version: 1.12.2
• Server Operating System/Architecture: Linux/x86

Additional Context:

AFAICT, this issue forces the use of the authenticated endpoint for retrieving the public_key in a vault template, which also forces granting read capability to /ssh/config/ca. I haven't been able, by trial or reading the consul template docs, to modify the behavior to handle a text/plain server response.

[cipherboy]

@rjhornsby -format=raw will allow you to read Vault secrets of this manner, see related PKI issues for historical context. For Agent, I'm not sure if there's a workaround.

[maxb]

The signing key of an SSH secrets engine would typically be a long-lived, non-rotated key. As such, it would not usually be managed via Vault Agent, and would instead be incorporated into machine SSHD configuration during the process of building a machine.

If there is a use-case for Vault Agent handling this data, could you elaborate on it, @rjhornsby ?

[rjhornsby]

If there is a use-case for Vault Agent handling this data

It is perhaps my own incorrect assumptions at play here. Long before I knew the vault agent was even a thing, I built an internal library on top of vault-ruby for chef to be able to retrieve kv secrets on behalf of cookbooks, and that's primarily what we use to get the secret values from vault to where they need to be. Using the agent as more than a pass-through/proxy/caching entity for a localhost is a relatively new approach for us.

It's quite reasonable to make a raw HTTP call to the unauthenticated endpoint for the signing key, but somewhere in my head it seemed to make sense that the agent would be the thing to handle this case. Maybe a case of hammer, meet what looks like a nail. The logic wasn't so much focused on the key's TTL, but rather the agent's capability to take a template and create a file for other processes like sshd to consume, and as a sort of side effect ensure if the key needed to be renewed/refreshed the agent would handle it transparently.