To use a key type that is:
- supported by all backends.
- can be generated with the most recent `ssh-keygen` version.
- here to stay for the foreseeable future.
(DSA is scheduled for removal from the libssh2 codebase.)
Cherry-picked from #2598Closes#2604
Implement server hostkey verification for the six ECDSA/RSA OpenSSH
certificate hostkey variants:
- `ecdsa-sha2-nistp256-cert-v01@openssh.com`
- `ecdsa-sha2-nistp384-cert-v01@openssh.com`
- `ecdsa-sha2-nistp521-cert-v01@openssh.com`
- `ssh-rsa-cert-v01@openssh.com`
- `rsa-sha2-256-cert-v01@openssh.com`
- `rsa-sha2-512-cert-v01@openssh.com`
This fixes#2434, where these algorithms were advertised and accepted as
preferences but had `NULL` hostkey `init`/`sig_verify` callbacks. A
certificate-only hostkey offer therefore caused
`LIBSSH2_ERROR_KEX_FAILURE (-5)`.
## Implementation
- ECDSA certificate parsing uses one shared init path for all three
curves. It validates the certificate type, nonce, inner curve name, and
EC point before constructing the verification context.
- RSA certificate parsing uses one shared init path for all three RSA
signature variants.
- Per-algorithm RSA `sig_verify` callbacks remain distinct.
- Per `PROTOCOL.certkeys`, the RSA/SHA-2 certificate blob itself carries
the type string `ssh-rsa-cert-v01@openssh.com`; the negotiated SHA-2
algorithm is represented by KEXINIT and the exchange signature.
- Certificate CA trust validation remains out of scope, consistent with
existing plain-hostkey handling.
## Tests
- Host CA fixtures (`keys/ca_host_ecdsa`, `keys/ca_host_rsa`) and
CA-signed host certificates for the ECDSA P-256 and RSA host keys in the
Docker OpenSSH fixture.
- The certificate algorithms are exercised through `test_read_algos.txt`
and `FIXTURE_TEST_HOSTKEY`: `ecdsa-sha2-nistp256-cert-v01@openssh.com`,
`rsa-sha2-256-cert-v01@openssh.com`,
`rsa-sha2-512-cert-v01@openssh.com`, `ssh-rsa-cert-v01@openssh.com`,
plus the pre-existing `ssh-ed25519-cert-v01@openssh.com`.
- The ECDSA P-384/P-521 certificate variants share the same codepath and
are covered by it; only P-256 is tested directly to keep the fixture
matrix lean (per maintainer review feedback).
- Disabled-backend skip entries in `tests/session_fixture.c` for the new
certificate algorithms.
- Preserved the existing ed25519 certificate test path.
Fixes#2434
Follow-up to 6036e57720#2513
Follow-up to 65a276e8fe#2064Closes#2539
- add host CA keys.
- add ed25519 signed hostkey for tests.
- make hostkey tests recognize it and skip hash checks.
- make existing tests select hostkey algos.
- add `ssh-ed25519-cert-v01@openssh.com` to the list of tested algos.
(exclude for unsupported backends.)
Ref: #2434
Inspired-by: #2435
Credits-to: Pier Carlo Cadoppi
Follow-up to 65a276e8fe#2064Closes#2513
They are supported via the backends, except OS/400 which has its own
parser, leaving libgcrypt and WinCNG (untested) without support. With
mbedTLS PKCS8 encryption (aes-128-cbc) requires 3.6.0+.
Add RSA, ECDSA and ED25519 keys.
What I find interesting in PKCS8 private keys, is the easy way to
inspect the ASN.1 content (`openssl asn1parse -dump -in <fn>`). I could
not find similar tooling for PEM and OpenSSH files.
Also:
- tests/openssh_server/authorized_keys: sync up comments with private
keys and the generator script.
Ref: https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.6.0Closes#2500
To improve coverage. This is the 'EC PRIVATE KEY` format, not tested
before. The encrypted flavor probably should not be used nowadays due to
its dependence on MD5, and thus also only tested in one job. Also use
this opportunity to introduce ECDSA 521 into the mix.
Also:
- test_auth_pubkey_ok_rsa_encrypted: require `LIBSSH2_AES_CBC`.
Closes#2499
Make it 256-bit to add variation.
Choose aes256-ctr for encryption to keep it compatible with mbedTLS,
which lacks AES-GCM support. (The other alternative, chacha-poly, has
decryption broken for keys.)
Closes#2486
The PR implementing this did not add anything OpenSSL-specific, yet it
gated the feature OpenSSL only. Turns out the reason for this is that
the test RSA keys are in OpenSSH format, which is only supported by
OpenSSL (and wolfSSL) in libssh2.
Fix by converting the two test keys to PEM format, making them
compatible with all backends. (RSA OpenSSH key format is already tested
separately.)
Also: this also fixes outdated comment fields present in these keys.
Bug: https://github.com/libssh2/libssh2/pull/1314#discussion_r3542830756
Ref: #2252 (initial fix attempt)
Follow-up to 1410efad7a#2249
Follow-up to 3a6ab70dcf#1314Closes#2483
Explicitly use `-t ssh-rsa` (signature algorithm) to generate
`id_rsa_signed.pub` to match the purpose of the patch it came with. Also
to differenciate this key (and test) from the subsequently merged
`id_rsa_sha2_512_signed-cert.pub`, which used the exact same keys (`-t
rsa-sha2-512`, the default) before this patch, and made these tests
duplicates.
Also:
- update `sshd_config` to actually allow using an obsolete/insecure
certificate signature `ssh-rsa`, by adding it to `CASignatureAlgorithms`.
- delete recently added entry from `HostKeyAlgorithms`, it was not
necessary.
Follow-up to 5b494b04b1#2478
Testing obsolete/insecure algs is not time best spent in CI and for
maintainers, so maybe in a next step it'd useful to disable the RSA
SHA1-based ones by default.
Ref: https://superuser.com/questions/1556852/how-to-check-if-your-ssh-keys-are-in-the-ssh-rsa2-format
Ref: 7392dc95dc#2479
Follow-up to 4b21e49d9d#710Closes#2474
The committed key was in reality `rsa-sha2-512`, not `rsa-sha2-256`, as
the filenames suggested.
Also set the type explicitly to `rsa-sha2-512`, to avoid relying on
ssh-keygen's default (`rsa-sha2-512`).
```shell
$ grep -E -o ' .+ ' id_rsa_sha2_512_signed-cert.pub | base64 -d | strings | grep -i rsa
```
Bug: #2474
Follow-up to 3a6ab70dcf#1314Closes#2479
Also:
- switch to `id_` prefix in comments to match filenames.
- use empty comment to add variation.
- spacecheck: allow trailing spaces for `.pub` files, this is how
`ssh-keygen -C ''` generates them.
Closes#2472
Also:
- replace the prefix `key_` with `id_` to match defaults and make them
easier to identify.
- rename `gen_keys.sh` to `keys-generate.sh`.
- include `keys-generate.sh` in tarball.
Closes#2471
