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

x/crypto/ssh: add support for multi-step authentication #17889

Open
thinxer opened this Issue Nov 11, 2016 · 3 comments

Comments

Projects
None yet
4 participants
@thinxer
Copy link

thinxer commented Nov 11, 2016

Previous thread here: https://groups.google.com/forum/#!topic/golang-nuts/rxrYhntkQtI.

Currently the x/crypto/ssh package uses callbacks in ServerConfig to do the autentication. Supported callbacks including "password,publickey,keyboard-interactive", and the client authenticates successfully with any of the callbacks.

This makes it impossible to implement multi-step authentication correctly. An example multi-step authentication process is to do publickey first, then keyboard-interactive to verify OTP tokens. When a client attempts to login, the server must first respond with only publickey available. When the client successfully completes the first stage, the server will respond with an authentication error with PartialSuccess set, and with the next available method keyboard-interactive. The client then knows it can continue with the second stage.

I'd propose to add a NextAuthMethodsCallback to ssh.ServerConfig. An example implementation is here: https://gist.github.com/thinxer/637acd43480174fede118704f27530a6#file-authmethods-patch.

If this change looks good, I will add tests and submit a patch for code review.

@thinxer thinxer changed the title x/crypto/ssh: does not support multi-step authentication x/crypto/ssh: add support for multi-step authentication Nov 11, 2016

@quentinmit quentinmit added this to the Unreleased milestone Nov 14, 2016

@hanwen

This comment has been minimized.

Copy link
Contributor

hanwen commented Jan 9, 2017

the FR seems valid in principle. The 1st approach seems sane, but I need a code review to look at it in more detail.

@danp

This comment has been minimized.

Copy link
Contributor

danp commented Jan 13, 2017

We are doing publickey + keyboard-interactive currently with a workaround:

We generate a ServerConfig per client with callbacks to methods on the client. Then as KeyboardInteractiveCallback and PublicKeyCallback are called we note what has succeeded so far, with either callback returning success if everything has been satisfied.

Probably would be nicer to explicitly start with publickey, get that taken care of, then explicitly move to keyboard-interactive.

@hanwen

This comment has been minimized.

Copy link
Contributor

hanwen commented Jan 17, 2017

what danp is doing is OK, but nothing sets PartialSuccess in the return message. I think we could have a specialized error type that an auth callback could hand back that causes PartialSuccess to be set. Possibly that should also error should also contain the next desired auth method.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.