SSH.NET Fails to Strictly Adhere to SSH Protocol Standards

[Aimeast]

Issue Summary: SSH.NET Fails to Strictly Adhere to SSH Protocol Standards

1. Elliptic Curve Name Case Sensitivity

According to [RFC 5656], the elliptic curve name must strictly match the defined format, which is case-sensitive. For example, nistp256 (all lowercase) is the correct identifier for the NIST P-256 curve. However, SSH.NET incorrectly accepts nistP256 (mixed case) without raising an error.

Observed Behavior:

• SSH.NET tolerates curve names with incorrect case (e.g., nistP256), while strict implementations like OpenSSH reject these values, leading to compatibility issues.

Impact:

• This behavior violates the SSH protocol standard, potentially causing interoperability problems with compliant clients/servers.
• It may obscure configuration errors, leading to production issues that are difficult to debug.

Suggested Fix:

• Ensure that SSH.NET strictly enforces case-sensitive validation of elliptic curve names as defined in the standard.

---

2. Improper Handling of ECDSA Signature Format

The ECDSA signature in SSH must follow the format specified in RFC 4253:

• The signature is an ecdsa_signature_blob containing two mpint values: r and s.

However, SSH.NET does not validate the format of the signature and accepts invalid representations, such as encoding r and s as octet strings instead of mpint.

Observed Behavior:

• When the server sends an invalid ECDSA signature (e.g., r and s encoded as octet strings), SSH.NET does not report an error.
• Strict clients, like OpenSSH, correctly reject such signatures with errors such as "Signature from server's host key is invalid."

Impact:

• Interoperability Risk: Inconsistent behavior when communicating with standards-compliant clients.
• Security Risk: Weak or incorrect signature validation could expose users to potential attacks (e.g., replay attacks or signature forgery).

Suggested Fix:

• Implement strict validation of the ecdsa_signature_blob to ensure r and s are properly formatted as mpint values.

---

3. Steps to Reproduce

Case Sensitivity Issue:

1. Configure SSH.NET to use the nistP256 curve name.
2. Attempt to connect to a strict client/server, such as OpenSSH.
3. Observe that SSH.NET establishes the connection, while OpenSSH rejects the curve name if it’s mismatched.

Invalid ECDSA Signature Issue:

1. Set up an SSH server to send an ECDSA signature with r and s encoded as octet strings.
2. Use SSH.NET to connect to the server.
3. Observe that SSH.NET accepts the connection, while OpenSSH fails with a signature validation error.

---

4. Proposed Actions

• Validation Enforcement: Add strict checks for curve names and signature format in SSH.NET.
• Comprehensive Testing: Introduce test cases to cover protocol edge cases and ensure compliance with RFC standards.
• Community Discussion: Gather feedback on the potential impacts of enforcing stricter validation and provide configuration options if needed.

---

5. References

• [RFC 4253: SSH Transport Layer Protocol]
• [RFC 5656: Elliptic Curve Algorithm Integration]
• [OpenSSH Source Code]

[Rob-Hague]

sounds reasonable, do you plan to raise a PR?