Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
crazed opened this issue Jun 7, 2021 · 12 comments
Open

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

crazed opened this issue Jun 7, 2021 · 12 comments
Labels
Proposal Proposal-Crypto Proposal related to crypto packages or other security issues
Milestone

Comments

@crazed
Copy link

crazed commented Jun 7, 2021

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?

@gopherbot gopherbot added this to the Proposal milestone Jun 7, 2021
@ianlancetaylor ianlancetaylor changed the title proposal: x/crypto/ssh expose client/sever supported algorithms proposal: x/crypto/ssh: expose client/sever supported algorithms Jun 7, 2021
@ianlancetaylor ianlancetaylor added the Proposal-Crypto Proposal related to crypto packages or other security issues label Jun 7, 2021
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals (old) Jun 7, 2021
@ianlancetaylor
Copy link
Contributor

CC @FiloSottile

@seankhliao
Copy link
Member

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

@crazed
Copy link
Author

crazed commented Nov 2, 2021

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.

@seankhliao seankhliao reopened this Nov 3, 2021
@gopherbot
Copy link
Contributor

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

@hanwen
Copy link
Contributor

hanwen commented Jan 12, 2023

FWIW, I support this change.

@crazed
Copy link
Author

crazed commented Feb 14, 2023

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
Copy link
Contributor

hanwen commented Feb 14, 2023

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
Copy link
Contributor

hanwen commented Feb 14, 2023

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
Copy link
Author

crazed commented Feb 14, 2023

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
Copy link
Contributor

hanwen commented Feb 21, 2023

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
Copy link
Author

crazed commented Feb 22, 2023

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
Copy link
Contributor

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

drakkan added a commit to drakkan/crypto that referenced this issue May 23, 2024
Fixes golang/go#58523
Fixes golang/go#46638

Change-Id: Ic64bd2fdd6e9ec96acac3ed4be842e2fbb15231d
drakkan added a commit to drakkan/crypto that referenced this issue Jun 4, 2024
Fixes golang/go#58523
Fixes golang/go#46638

Change-Id: Ic64bd2fdd6e9ec96acac3ed4be842e2fbb15231d
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Proposal Proposal-Crypto Proposal related to crypto packages or other security issues
Projects
Status: Incoming
Development

No branches or pull requests

5 participants