-
Notifications
You must be signed in to change notification settings - Fork 2k
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
ssh/knownhosts: check more than one key #254
base: master
Are you sure you want to change the base?
Conversation
This PR (HEAD: adcf924) has been imported to Gerrit for code review. Please visit https://go-review.googlesource.com/c/crypto/+/478535 to see it. Tip: You can toggle comments from me using the |
Message from Gopher Robot: Patch Set 1: Congratulations on opening your first change. Thank you for your contribution! Next steps: Most changes in the Go project go through a few rounds of revision. This can be During May-July and Nov-Jan the Go project is in a code freeze, during which Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
Any progress? Love to see this merged. Thanks! |
One potential downside to this PR is it changes the documented behavior of knownhosts.KeyError.Want, re: "For each key algorithm there can be one hostkey" type KeyError struct {
// Want holds the accepted host keys. For each key algorithm,
// there can be one hostkey. If Want is empty, the host is
// unknown. If Want is non-empty, there was a mismatch, which
// can signify a MITM attack.
Want []KnownKey
} @lonnywong out of curiosity, do you really have 2 keys of the same type for the same hostname (same situation as golang/go#36126, which would be solved by this PR)? Or do you have a server presenting multiple hostkeys of different types, some of which aren't in the client knownhosts file (see golang/go#29286)? Both issues result in the same user-facing error on the client side, but they have different root causes. In my experience, the latter situation is much more common. I have a widely-used package, github.com/skeema/knownhosts, which uses some trickery to provide a workaround for golang/go#29286, although it doesn't help with golang/go#36126. Just mentioning this here because github.com/skeema/knownhosts currently assumes the "For each key algorithm there can be one hostkey" logic remains the case, although I don't think it would break anything if that changes -- pretty sure it would just lead to potential duplicate entries in ssh.ClientConfig.HostKeyAlgorithms which hopefully is harmless? Anyway that should be easy to solve if it is a problem. Not sure if other packages out there depend on that logic more strictly though. |
@evanelias Thanks very much for your help. My case is multiple hostkeys of different types. I didn’t find golang/go#29286 before. I’ll try your awesome package https://github.com/skeema/knownhosts this weekend. Thanks again. |
Currently the behavior of HostKeyAlgorithms never contains duplicates, only by virtue of golang.org/x/crypto/ssh/knownhosts exposing a maximum of one key per algorithm in its KeyError.Want slice. However, that upstream behavior could theoretically change in the future, especially since golang.org/x/crypto is versioned as a pre-v1 module, and the one-key-per-type behavior is only documented as a comment (e.g. not part of any type or function signature). This commit makes our HostKeyAlgorithms function more robust / future-proof by ensuring that its result does not contain duplicates, regardless of upstream behavior. This means if golang/go#28870 is solved (for example by golang/crypto#254), there should not be any harm to our behavior here in github.com/skeema/knownhosts.
Message from Gopher Robot: Patch Set 1: Congratulations on opening your first change. Thank you for your contribution! Next steps: Most changes in the Go project go through a few rounds of revision. This can be During May-July and Nov-Jan the Go project is in a code freeze, during which Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
anything I can do to help move this forward? |
@caarlos0 We do code review on Gerrit, and as noted above this pull request is https://go.dev/cl/478535. If you look there you will see some unresolved comments. The first step to moving this forward is resolving them one way or another. Thanks. |
@ianlancetaylor yep, I'm aware, the comments were posted after I asked here, though... anyway, will fix them |
adcf924
to
58ab267
Compare
Message from Nicola Murino: Patch Set 1: Code-Review+2 (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
Message from Nicola Murino: Patch Set 1: Commit-Queue+1 Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
Message from Go LUCI: Patch Set 1: Dry run: CV is trying the patch. Bot data: {"action":"start","triggered_at":"2024-07-27T14:23:24Z","revision":"5f775643e919a2ef667482957769e4ab56121bdc"} Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
Message from Nicola Murino: Patch Set 1: -Commit-Queue Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
Message from Go LUCI: Patch Set 1: This CL has failed the run. Reason: Tryjob golang/try/x_crypto-gotip-linux-amd64 has failed with summary (view all results):
Build or test failure, click here for results. Additional links for debugging: Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
Message from Go LUCI: Patch Set 1: LUCI-TryBot-Result-1 Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
Message from Nicola Murino: Patch Set 1: Commit-Queue+1 Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
Message from Go LUCI: Patch Set 1: Dry run: CV is trying the patch. Bot data: {"action":"start","triggered_at":"2024-07-27T14:58:01Z","revision":"5f775643e919a2ef667482957769e4ab56121bdc"} Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
Message from Nicola Murino: Patch Set 1: -Commit-Queue Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
Message from Go LUCI: Patch Set 1: This CL has failed the run. Reason: Tryjob golang/try/x_crypto-go1.21-linux-amd64 has failed with summary (view all results):
Build or test failure, click here for results. Additional links for debugging: Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
Message from Filippo Valsorda: Patch Set 1: Code-Review+1 Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
Message from Filippo Valsorda: Patch Set 1: (2 comments) Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
Message from Filippo Valsorda: Patch Set 1: (1 comment) Please don’t reply on this GitHub thread. Visit golang.org/cl/478535. |
This PR (HEAD: 58ab267) has been imported to Gerrit for code review. Please visit Gerrit at https://go-review.googlesource.com/c/crypto/+/478535. Important tips:
|
The problem was that it was keeping only the first known key of each type found. If you have a server advertising multiple keys of the same type, you might get a missmatch key error. Per `sshd(8)` man page, it should allow reapeatable hosts with different host keys, although it don't specify anything about hosts being from different types: > It is permissible (but not recommended) to have several lines or > different host keys for the same names. This will inevitably happen when > short forms of host names from different domains are put in the file. It > is possible that the files contain conflicting information; > authentication is accepted if valid information can be found from either > file. So, this changes `knownhosts` behavior to accept any of the keys for a given host, regardless of type. Fixes #36126 Signed-off-by: Carlos Alexandro Becker <caarlos0@users.noreply.github.com>
58ab267
to
2ccd649
Compare
This PR (HEAD: 2ccd649) has been imported to Gerrit for code review. Please visit Gerrit at https://go-review.googlesource.com/c/crypto/+/478535. Important tips:
|
I believe this fixes golang/go#36126 .
The problem was that it was keeping only the first known key of each
type found.
If you have a server advertising multiple keys of the same type,
you might get a missmatch key error.
Per
sshd(8)
man page, it should allow reapeatable hosts withdifferent host keys, although it don't specify anything about
hosts being from different types:
So, this changes
knownhosts
behavior to accept any of the keys for agiven host, regardless of type.
Fixes #36126