community.crypto
community.crypto copied to clipboard
openssh_cert signature_algorithm does not list all choices
I've noticed that the openssh_cert does list only three signature_algorithm choices https://github.com/ansible-collections/community.crypto/blob/16434d9ad85dedb7007e5d2d7b1e2481134d45b7/plugins/modules/openssh_cert.py#L567 while ssh -Q key-ca-sign currently shows more:
ssh-ed25519
[email protected]
ecdsa-sha2-nistp256
ecdsa-sha2-nistp384
ecdsa-sha2-nistp521
[email protected]
[email protected]
ssh-rsa
rsa-sha2-256
rsa-sha2-512
Related: #813
I'd like to upgrade this issue to a bug because choices limits the algorithms to only the ones specified without actually checking with the current implementation i.e. what ssh-keygen would accept for that matter:
$ ansible -m community.crypto.openssh_cert -a "type=host signature_algorithm=ed25519 signing_key=temp public_key=temp.pub path=cert valid_from=always valid_to=forever" localhost
[WARNING]: No inventory was parsed, only implicit localhost is available
localhost | FAILED! => {
"changed": false,
"msg": "value of signature_algorithm must be one of: ssh-rsa, rsa-sha2-256, rsa-sha2-512, got: ed25519"
}
Leaving signature_algorithms unspecified seems to work:
$ ansible -m community.crypto.openssh_cert -a "type=host signing_key=temp public_key=temp.pub path=cert valid_from=always valid_to=forever" localhost
[WARNING]: No inventory was parsed, only implicit localhost is available
localhost | SUCCESS => {
"changed": false,
"filename": "cert",
"info": [
"Type: [email protected] host certificate",
"Public key: ED25519-CERT SHA256:zXqsmzLlNZTWPSWNhJuQ7mUuw5irKPGzUAsY6z5AghU",
"Signing CA: ED25519 SHA256:zXqsmzLlNZTWPSWNhJuQ7mUuw5irKPGzUAsY6z5AghU (using ssh-ed25519)",
"Key ID: \"\"",
"Serial: 0",
"Valid: forever",
"Principals: (none)",
"Critical Options: (none)",
"Extensions: (none)"
],
"type": "host"
}
Now, openssh_cert calls KeygenCommand.generate_certificate which uses the signature_algorithm as value for option -t for ssh-keygen: https://github.com/ansible-collections/community.crypto/blob/main/plugins/module_utils/openssh/backends/common.py#L181
Looking through the man page for ssh-keygen(1), it only specifies a key type -t when generating new key pairs:
SYNOPSIS
ssh-keygen [-q] [-a rounds] [-b bits] [-C comment] [-f output_keyfile] [-m format] [-N new_passphrase] [-O option]
[-t ecdsa | ecdsa-sk | ed25519 | ed25519-sk | rsa] [-w provider] [-Z cipher]
[...]
Is the module using an undocumented feature of ssh-keygen?
I'd like to upgrade this issue to a bug because
choiceslimits the algorithms to only the ones specified without actually checking with the current implementation i.e. whatssh-keygenwould accept for that matter:
That's not the definition of a bug, but exactly the definition of a new feature. The module currently supports a certain set of choices, and you want more choices. That's a feature request. Not a bug.
Even if this module would simply only call ssh-keygen, this would NOT be a bug, but a feature request.
I very much tend to agree with you.
- It is not a bug (and maybe not even a feature request) because I can simply leave signature_algorithms unspecified, use an ed25519 key, and the module does the right thing, namely creating a ed25519 signed certificate because ssh-keygen seems to derive the signature algorithm from the signing key and in case of multiple options, choose the
- ~~It is a bug because if I explicitly specify ed25519 signature_algorithms, the module throws an error, although it "knows" how to create ed25519 signatures (see above).~~ The documentation says the module will fail if any other type than rsa is given.
- ~~It is undefined behaviour because the module correctly creates an ed25519 certificate with an ed25519 key, although it is not supported via signature_algorithms but only implicitly by specifying the signing key.~~ The documentation says the module will fail if any other type than rsa is given.
The module (ssh-keygen) also correctly derives the signature algorithm for ecdsa (256, 384, 521) and there is only the one option for each key (as with ed25519).
So in the end, I'm OK with not changing anything because in my opinion, nothing needs changing :) (apart from the undocumented -t option for ssh-keygen -s)
Sorry for the noise.