[Ovmsdev] wolfssh vs openssh 8.8p1

[Craig Leres]

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