Remove SSH version 1 support

[jtesta]

I propose that the unmaintained SSH version 1 support be removed. Rationale is as follows:

1. It may already be broken ever since v2.0.0 (released in 2019). Testing has never been done on it after many, many rounds of extensive organizational changes and new features (!).
2. There is no practical point to parsing SSHv1, since the entire protocol is critically broken. Knowing that vulnerable algorithm X is enabled doesn't change the fact that the entire protocol must be disabled (in other words, hardening the algorithm list is pointless). Instead, we can simply detect if v1 is enabled, and issue a failure.
3. Removal of support would reduce the number of lines of code in the codebase. For example:

• https://github.com/jtesta/ssh-audit/blob/v3.2.0/src/ssh_audit/ssh_audit.py#L691
• https://github.com/jtesta/ssh-audit/blob/v3.2.0/src/ssh_audit/ssh1.py
• https://github.com/jtesta/ssh-audit/blob/v3.2.0/src/ssh_audit/ssh1_crc32.py
• https://github.com/jtesta/ssh-audit/blob/v3.2.0/src/ssh_audit/ssh1_kexdb.py
• https://github.com/jtesta/ssh-audit/blob/v3.2.0/src/ssh_audit/ssh1_publickeymessage.py

I will take input from the community on this change. If anyone agrees with this proposal, put a thumbs-up emoji on this comment ( 👍 ). Otherwise, if you'd like to keep SSH version 1 support, put a thumbs-down emoji on this comment ( 👎 ). Voting will remain open until April 1, 2025 (for approximately 6 months). After that time, I'll follow whatever the community prefers.

[perkelix]

Removing SSH1 auditing and issuing a LOUD RED blanket error if SSH1 is found enabled at all seems like a good idea.

[BenBE]

Somewhat mixed about this:

Pro:

• Reduce code complexity
• Insecure anyway, thus no need to differentiate badness

Con:

• Limits informational/statistical usecases (e.g. key/algorithm tracking)

[jtesta]

Limits informational/statistical usecases (e.g. key/algorithm tracking)

Is there any real-world scenario where ssh-audit is being used to collect statistics on SSHv1 algorithms?

[BenBE]

Limits informational/statistical usecases (e.g. key/algorithm tracking)

Is there any real-world scenario where ssh-audit is being used to collect statistics on SSHv1 algorithms?

I'd guess they are rare, but given ssh-audit allows key extraction it's not impossible that ssh-audit is used in that way.

[NathanRodet]

What about forking the latest version with SSH-1 support and mention it as available in a separate unmaintained repository ?

[BenBE]

Or more easily, tag it and reference it in the README to the effectively same effect …

[jtesta]

What about forking the latest version with SSH-1 support and mention it as available in a separate unmaintained repository ?

@NathanRodet : anyone interested in parsing SSHv1 endpoints could just do git clone --branch v3.x.x to get the last stable version that supports it (if it even works--as mentioned above, the SSHv1 code has not been tested in the last 5 years and may never have worked!).