Selecting any algorithm_signer for a ssh engine causes sign error

[lhw]

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

1. vault secrets enable ssh
2. ssh-keygen -C ca -t ed25519 -f ca -N '' 
3. vault write ssh/config/ca private_key=@ca public_key=@ca.pub
4. vault write ssh/roles/role allow_user_certificates="true" key_type="ca"
5. ssh-keygen -C user -f user -N ''
6. vault write ssh/sign/role public_key=@user.pub -> SUCCESS
7. vault write ssh/roles/role allow_user_certificates="true" key_type="ca" algorithm_signer="ssh-rsa"
8. vault write ssh/sign/role public_key=@user.pub -> FAILURE

Code: 500. Errors:
* 1 error occurred:
        * failed to generate signed SSH key: sign error

(I wonder how often the user ca is quoted in this kind of context)

Expected behavior
Selecting an, as per documentation, secure signing algorithm should not cause a signing error.

Environment:

• Vault Server Version (retrieve with vault status): 1.5.4
• Vault CLI Version (retrieve with vault version): 1.5.4 (1a73077)
• Server Operating System/Architecture: Ubuntu 20.04.1

Vault server configuration file(s):
vault server -dev

Additional context

[pippo]

Not sure whether that's expected behaviour or not, however, it looks like this is failing because you're trying to use RSA algo while using ed25519 key for it.
Underlying error, coming from golang.org/x/crypto/ssh (here) is:

ssh: unsupported signature algorithm ssh-rsa

The issue does not reproduce with ed25519 changed to rsa at step 2 above.

Perhaps, the error could be a bit more informative, if the underlying error was appended to it. E.g.

failed to generate signed SSH key: sign error: ssh: unsupported signature algorithm ssh-rsa

[lhw]

ed25519 keys can sign rsa keys and the other way around. But the signer needs to select the correct signature algorithm. This probably means the #9824 was not expansive enough.

[lhw]

I wanted to bump this issue as clients on our side had to downgrade back to rsa for now after I got everyone to update to ed25519 keys.

[candlerb]

I did a quick test based on the OP's request. Actually, signing with an ed25519 CA key works just fine, as long as you rely on the default signing algorithm.

$ vault secrets enable -path sshtest ssh
Success! Enabled the ssh secrets engine at: sshtest/
$ ssh-keygen -C ca -t ed25519 -f ca -N ''
Generating public/private ed25519 key pair.
...
$ vault write sshtest/config/ca private_key=@ca public_key=@ca.pub
Success! Data written to: sshtest/config/ca
$ ssh-keygen -C user -f user -N ''
Generating public/private rsa key pair.
...
$ vault write sshtest/roles/role allow_user_certificates="true" key_type="ca" algorithm_signer=""
Success! Data written to: sshtest/roles/role
$ vault write -field signed_key sshtest/sign/role public_key=@user.pub >user-cert.pub
$ ssh-keygen -Lf user-cert.pub
user-cert.pub:
        Type: ssh-rsa-cert-v01@openssh.com user certificate
        Public key: RSA-CERT SHA256:Xrt2BvjS55fZNQkuAz1xwbu5KiHSgKrHpPL/nLmKGmQ
        Signing CA: ED25519 SHA256:CxqReZWqA18B8w0n9XJ0jdyaB/UxpR8fUFtKjAzFW/4 (using ssh-ed25519)
        Key ID: "vault-root-5ebb7606f8d2e797d935092e033d71c1bbb92a21d280aac7a4f2ff9cb98a1a64"
        Serial: 9028463485372532358
        Valid: from 2021-03-03T11:07:08 to 2021-04-04T11:07:38
        Principals: (none)
        Critical Options: (none)
        Extensions: (none)

There you go: RSA user key signed by ED25519 CA. And it works for ED25519 user key signed by ED25519 CA as well:

$ ssh-keygen -C user -t ed25519 -f user2 -N ''
Generating public/private ed25519 key pair.
...
$ vault write -field signed_key sshtest/sign/role public_key=@user2.pub >user2-cert.pub
$ ssh-keygen -Lf user2-cert.pub
user2-cert.pub:
        Type: ssh-ed25519-cert-v01@openssh.com user certificate
        Public key: ED25519-CERT SHA256:KiBqY0/C9sqX4cjmP7/+5HqJ7lfK7JMSgsWyP58qmdU
        Signing CA: ED25519 SHA256:CxqReZWqA18B8w0n9XJ0jdyaB/UxpR8fUFtKjAzFW/4 (using ssh-ed25519)
        Key ID: "vault-root-2a206a634fc2f6ca97e1c8e63fbffee47a89ee57caec931282c5b23f9f2a99d5"
        Serial: 6331755275642996610
        Valid: from 2021-03-03T11:11:15 to 2021-04-04T11:11:45
        Principals: (none)
        Critical Options: (none)
        Extensions: (none)

The main problem is you can't choose the algorithm in algorithm_signer:

$ vault write sshtest/roles/role allow_user_certificates="true" key_type="ca" algorithm_signer="ssh-ed25519"
...
* 1 error occurred:
	* unknown algorithm signer "ssh-ed25519"
$ vault write sshtest/roles/role allow_user_certificates="true" key_type="ca" algorithm_signer="sk-ssh-ed25519@openssh.com"
...
* 1 error occurred:
	* unknown algorithm signer "sk-ssh-ed25519@openssh.com"

(EDIT: of course, when the CA key type is ed25519, you'd never want to choose an RSA-based signature algorithm like sha-rsa. This is true even when you're signing a user key which happens to be RSA. The signature is made using ed25519, not RSA)

In practice, you probably never need to specify the signing algorithm, except when the key type is RSA: in which case, it's just a question of documentation ("other CA key types are allowed, but you must you leave algorithm_signer blank")

That just leaves the feature request to specify a non-RSA key type when using generate_signing_key (EDIT: now raised as #11035). Otherwise, your CA private key is exposed when it is generated externally and imported into vault. If you do it carefully, e.g. onto a ramdisk, you're probably OK.

[candlerb]

Checking in crypto/ssh source, the only cases where you can specify the algorithm signer are RSA. In all other cases, the algorithm signer must be either blank or equal to the key type - and both these cases are treated identically. In this case, requiring blank for all non-RSA CA keys is perfectly fine.

[lhw]

I'm fairly certain I also tried executing the commands without a selected algorithm_signer and it did not work at the time. But I might be wrong it has been quite a few months.

But it's nice to see that this does work and I can tell my users that they can use their keys again as they used too.

[candlerb]

Excellent. Just be to be clear: you can keep your CA as RSA, and users can use ed25519 keys; or you can have a CA which is ed25519 and the users have RSA keys. There's no need for the signing key to be of the same type as the user key.

algorithm_signer depends only on the key type used in the CA, not the key type of the user. If the CA key is RSA, then algorithm_signer can be empty or ssh-rsa (which are the same), or rsa-sha2-256, or rsa-sha2-512. For any other CA key type, algorithm_signer must be empty.

[calvn]

The algorithm_signer param supports any of the SigAlgo* const values within the ssh package. Note that this is different from the algorithm for the key type itself, and is only really applicable when signing certs using a RSA CA key to specify a specific signature variant, similar to ssh-keygen's -t flag when it comes to this specific behavior [1]. @candlerb's last comment is pretty much on point -- unless your CA key is RSA, leaving algorithm_signer empty should do the trick.

[1]:

This flag may also be used to specify the desired signature type when signing certificates using an RSA CA key. The available RSA signature variants are “ssh-rsa” (SHA1 signatures, not recommended), “rsa-sha2-256”, and “rsa-sha2-512” (the default).

[lhw]

Yes. I will go ahead and close the issue as my problem is definitely solved.

[candlerb]

BTW, I also provided pull request #11036 to clarify the documentation and give a better error than just "sign error".