proposal: x/crypto/ssh: expose client/sever supported algorithms

[crazed]

When working with a variety of SSH client/server software, it can be useful to expose the supported Key Exchange, MAC, and Ciphers for both client and server side. Primarily this allows someone to answer questions like, "if we remove support for X, will any of our clients fail?."

When looking into this, initially I thought we could expose this on the ConnMetadata interface (*sshConn implements this), and additionally extend ssh.Client with a new GetConnMetadata() ConnMetadata function which returns the underlying *sshConn.

This would involve exposing the values stored in the server/client *kexInitMsg on up, possibly through new fields on *handshakeTransport as clientInitMsg *kexInitMsg and serverInitMsg *kexInitMsg.

Is this something that would be appropriate for a PR or are other implementation options preferred here?

[ianlancetaylor]

CC @FiloSottile

[seankhliao]

I believe this can be closed as a duplicate of the declined #46232

[crazed]

I believe this can be closed as a duplicate of the declined #46232

This is not a duplicate, the referenced issue seems to be about the package as a whole supporting various algo types.

This issue is specifically about exposing what algorithms a client and server have negotiated as supporting during the connection setup process. Today there is no way to retrieve what was exposed by the client or server as acceptable options.

[gopherbot]

Change https://go.dev/cl/453976 mentions this issue: ssh: expose connection algorithms

[hanwen]

FWIW, I support this change.