openssh_keypair: Adding passphrase parameter

[Ajpantuso]

SUMMARY

Added passphrase paramter to openssh_keypair for encrypting/decrypting OpenSSH private keys.

ISSUE TYPE

• Feature Pull Request

COMPONENT NAME

plugins/modules/openssh_keypair
plugins/module_utils/openssh/cryptography_openssh

ADDITIONAL INFORMATION

openssh_keypair

• Uses cryptography instead of ssh_keygen to avoid passing passphrases over command line
• Maintains consistent formatting with ssh_keygen which changed in version 7.8
• Ensures idempotency checks behave as documented when using passphrase
• Return values are consistent with parsed ssh_keygen output
• passphrase is used as a switch so if empty or not supplied behavior will be the same as before this feature (Some more lines are included in try blocks, but are really just variable assignments)

cryptography_openssh

• Exposes SSH private key formatting capability as a global
• Added option to load a lone private key and automatically generate the corresponding public key
• Added option to explicitly select private key format
• Added logic to reattempt loading a PEM formatted private key if the OpenSSH loader fails
• Made it possible to set null comments
• Added "SHA256:" prefix to fingerprint

Integration tests have been updated as well.

Unfortunately the following containers have system packages of cryptography less than what is required to replicate the installed OpenSSH versions and the local pip versions are not able to install an updated version.

For these containers currently only the test cases which do not use the passphrase option are executed.

• CentOS 6
• CentOS 8
• openSUSE 15 py3
• Ubuntu 18.04
• RHEL 8.3
• FreeBSD 12.1
• FreeBSD 12.2
• FreeBSD 13.0

[felixfontein]

Thanks for this contribution! I really like it :)

What do you think of (probably more for a follow-up PR ;) ) adding backends to openssh_keypair, similar to the cryptography vs pyopenssl backends for some of the openssl_* modules? Assuming that the code for the cryptography backend would only rely on cryptography and no longer would need ssh-keygen.

[Ajpantuso]

Thanks for this contribution! I really like it :)

What do you think of (probably more for a follow-up PR ;) ) adding backends to openssh_keypair, similar to the cryptography vs pyopenssl backends for some of the openssl_* modules? Assuming that the code for the cryptography backend would only rely on cryptography and no longer would need ssh-keygen.

Freeing this module from ssh-keygen should be possible given it's current feature set.
I've researched other libraries while doing this and cryptography stands alone in terms of the OpenSSH specific features which are separate from the core OpenSSL library. And even then there are still gaps for example no support for generating SSH certificates which is critical for the openssh_cert module. If we maintained custom implementations of the OpenSSH formats that would open things up considerably....but then we would be stuck maintaining custom implementations of the OpenSSH formats :(

[felixfontein]

Freeing this module from ssh-keygen should be possible given it's current feature set.

Great!

I've researched other libraries while doing this and cryptography stands alone in terms of the OpenSSH specific features which are separate from the core OpenSSL library. And even then there are still gaps for example no support for generating SSH certificates which is critical for the openssh_cert module.

Well, I'd already be happy if only the openssh_keypair module has a cryptography backend and openssh_cert has not. I think there are a lot more people interested in openssh_keypair than there are in openssh_cert.

(openssl_pkcs12 is another module without cryptography backend BTW, since PKCS12 support in cryptography is very, very basic right now, and only available since 3.0 IIRC.)

If we maintained custom implementations of the OpenSSH formats that would open things up considerably....but then we would be stuck maintaining custom implementations of the OpenSSH formats :(

We definitely do not want to maintain that :-)

[felixfontein]

This should be at some point moved to tests/integration/targets/setup_bcrypt/ so it can be used by other integration tests as well. No need to do that in this PR though :)

[Ajpantuso]

Yes, sorry was just pushing through issues with CI so there's definitely cleanup work to be done.

[felixfontein]

Tell me whether you want to do more work on the PR right now, or in a follow-up PR.

[Ajpantuso]

Tell me whether you want to do more work on the PR right now, or in a follow-up PR.

I'm good to go with this PR for now.

[felixfontein]

@Ajpantuso thanks for working on this! :)