[Ovmsdev] wolfssh vs openssh 8.8p1

[Stephen Casner]

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 at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev