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.

[crazed]

Any updates as to when this will land? With OpenSSH and the general industry removing ssh-rsa in favor of rsa-sha2-512 and rsa-sha2-256 I'm about to be in a place where I need to track which connections are using the old ssh-rsa in order to smoothly transition off of that.

[hanwen]

I've taken up SSH maintenance again, and wrote a proposal over here #58523.

I'm glad I did, because it's now obvious we didn't think about the kex and hostkey algorithms either. I'll make sure this proposal gets through. In the meantime, maybe you can update the CL to expose type algorithms instead.

[hanwen]

I'm about to be in a place where I need to track which connections are using the old ssh-rsa in order to smoothly transition off of that.

They're only used for host keys, though? (for user auth, you can track them through the auth log callback).

[crazed]

They're only used for host keys, though? (for user auth, you can track them through the auth log callback).

I can't get the list of algos that the client/server connections support, just the client/server version strings. I could be missing something though.

Glad to hear about the proposal, if this becomes a real issue I'll try to extend the CL. For now easy enough to support both to maintain connectivity while everyone moves off but would be nice to know for reporting as mentioned in your proposal.

[hanwen]

I can't get the list of algos that the client/server connections support

I don't understand. If you run the server, you control the list of algos through the configuration, and you can inspect the source code to find the supported ones.

[crazed]

I can't get the list of algos that the client/server connections support

I don't understand. If you run the server, you control the list of algos through the configuration, and you can inspect the source code to find the supported ones.

That is true and I have set a limited configuration, however I have no ability to report or log what each connection is actually using (or what they advertise as supporting during connection set up). Without that reporting it is hard to turn off older algos in a manner where I can confirm no connectivity issues will be created.

[gopherbot]

Change https://go.dev/cl/538235 mentions this issue: ssh: expose negotiated algorithms