Unlike a certificate, I don’t think RSA keys are ‘signed’ in the file at all. My guess is the Sha-1 signing happens dynamically at Key exchange time in the Wolf library. Perhaps there is an option to enable Sha-256 for that? Regards, Mark
On 24 Oct 2021, at 1:05 PM, Stephen Casner <casner@acm.org> wrote:
Craig,
The WolfSSH API includes the function to make an RSA key, but I don't see any alternatives. The ciphers ecdsa and ed25519 are included in WolfSSL, but I don't know if manually supplying a host key generated with those algorithms would work since some of the metadata might still imply RSA.
If the problem is SHA-1, could an RSA host key be signed with SHA-256 hash instead? (But I don't see an option in the key generation to choose a differnt hash algorithm.)
-- Steve
On Sat, 23 Oct 2021, Craig Leres wrote:
I recently upgraded many systems to openssh-portable 8.8p1 which disables rsa/sha1 signatures by default. I believe my ovms modules are using ssh-rsa for their host keys:
ssh -vv ovms-z OpenSSH_8.8p1, OpenSSL 1.1.1l 24 Aug 2021 [...] debug1: kex: algorithm: ecdh-sha2-nistp256 debug1: kex: host key algorithm: (no match) Unable to negotiate with 172.16.1.88 port 22: no matching host key type found. Their offer: ssh-rsa
The suggested workaround works but is it possible for me to generate a ecdsa or ed25519 host key offline and install it in the module? Should we consider changing the key type generated on first use?
Craig
https://www.openssh.com/txt/release-8.8
Potentially-incompatible changes ================================
This release disables RSA signatures using the SHA-1 hash algorithm by default. This change has been made as the SHA-1 hash algorithm is cryptographically broken, and it is possible to create chosen-prefix hash collisions for <USD$50K [1]
For most users, this change should be invisible and there is no need to replace ssh-rsa keys. OpenSSH has supported RFC8332 RSA/SHA-256/512 signatures since release 7.2 and existing ssh-rsa keys will automatically use the stronger algorithm where possible.
Incompatibility is more likely when connecting to older SSH implementations that have not been upgraded or have not closely tracked improvements in the SSH protocol. For these cases, it may be necessary to selectively re-enable RSA/SHA1 to allow connection and/or user authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms options. For example, the following stanza in ~/.ssh/config will enable RSA/SHA1 for host and user authentication for a single destination host:
Host old-host HostkeyAlgorithms +ssh-rsa PubkeyAcceptedAlgorithms +ssh-rsa
We recommend enabling RSA/SHA1 only as a stopgap measure until legacy implementations can be upgraded or reconfigured with another key type (such as ECDSA or Ed25519).
[1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust" Leurent, G and Peyrin, T (2020) https://eprint.iacr.org/2020/014.pdf _______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev