-
Notifications
You must be signed in to change notification settings - Fork 17.3k
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: allow to change allowed authentication methods #66815
Comments
Change https://go.dev/cl/578735 mentions this issue: |
CC @golang/security |
The idea behind the proposal is sound: having a way to switch auth methods without returning I suggest creating an interface (internal or exported) that both // ChangeAuthMethods can be implemented by any error returned from auth callbacks to
// change the set of auth callbacks used for further attempts on this connection.
type ChangeAuthMethods interface {
NextAuthMethods() ServerAuthCallbacks
}
func (e *PartialSuccessError) NextAuthMethods() ServerAuthCallbacks { return e.Next }
func (e *ChangeAuthMethodsError) NextAuthMethods() ServerAuthCallbacks { return e.Next } An exported interface has the benefit of using error values to affect other behaviors, like sending banner messages. |
I don't think a ChangeAuthMethods interface composes well with BannerError for example, because we'd have to add NextAuthMethods to BannerError ourselves. Instead, we already have a mechanism to nest error types, which is Unwrap. We can document that we check for both BannerError, PartialSuccessError, and ChangeAuthMethodsError with errors.As, and then implementations can just compose them by nesting a ChangeAuthMethodsError in a BannerError (or more complex custom nesting by using their own type which Unwraps to all of those). |
Good point, |
I think Also, is a PartialSuccessError that wraps a non-nil error... not a partial success? It'd be a bit confusing. The nice thing about errors.As is that if you do need to make PartialSuccessError wrap something, you can implement your own partialSuccessErrorWrapper type with a |
This proposal has been added to the active column of the proposals project |
@drakkan and @FiloSottile what is the current status of this discussion. Is there a consensus for something? If so, what specifically? |
@rsc I think we should implement the original proposal and not add I think it makes sense to check for both |
@awly I rebased the CL 578735 and added some test cases for
So, by implementing the original proposal, it is possible to both dynamically change the allowed authentication methods (with or without returning partial success) and return a customized banner at the same time. Please let us know if this is enough for your use case. Thank you |
@drakkan yep, the original proposal works for us. My suggestions were mostly aimed at making the implementation simpler, but the API in this proposal looks good too. No objections here! |
It sounds like the new API is:
and nothing else. Do I have that right? |
I confirm, thank you! |
Based on the discussion above, this proposal seems like a likely accept. The new API is:
and nothing else. |
Proposal Details
Now that CL 516355 has been merged a server can dynamically change allowed authentication methods for a given user by returning a
PartialSuccessError
.When a
PartialSuccessError
is returned, the "partial success" boolean field in SSH_MSG_USERAUTH_FAILURE is set totrue
.I propose adding a new error that allows to change authentication methods without returning a partial success error
This is a cleaner approach to allowing modification of authentication methods and will reuse the logic already implemented for
PartialSuccessError
.The text was updated successfully, but these errors were encountered: