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: Additional information from HostKeyCallback or Handshake failure #16459

iaburton opened this issue Jul 21, 2016 · 3 comments


Copy link

iaburton commented Jul 21, 2016

Please answer these questions before submitting your issue. Thanks!

  1. What version of Go are you using (go version)?
  2. What operating system and processor architecture are you using (go env)?
  3. What did you do?
    Set a custom callback for ClientConfig HostKeyCallback
  4. What did you expect to see?
    My own error when creating a client connection that failed due to my HostKeyCallback.
    The server returns the error as-is
    I wrongly assumed my error would be passed through in a similar fashion to how Bolt's API works, so this isn't a bug/issue so much as it is a small feature request.
  5. What did you see instead?
    A new "generic" error wrapped by fmt.Errorf

So currently in the error I return from my HostKeyCallback I set additional information I'd like to retrieve later when making a client connection. Currently this is difficult because the error is always wrapped by fmt.Errorf at the line above. I know I can set additional state in my function (maybe a map with a mutex) or run a regex against the returned error to see if it contains my error, but neither of those seemed very good.

My idea is to add a simple HandshakeError type that saves a reference to the original error and is returned in the client handshake (maybe the sever handshake too). Something like this
There are already other Error types in that package, and this one would print the same output if someone was expecting it. Alternatively removing the fmt.Errorf call would work, and would match how the ssh server returns the error from its handshake, which ever is best.

Copy link

hanwen commented Jul 25, 2016

probably easiest to return the error unchanged.

@quentinmit quentinmit added this to the Unreleased milestone Jul 29, 2016
Copy link

iaburton commented Aug 4, 2016

That would be nice. Is this something that can be included in another commit due to it being a single line change? Or should I do it and go through the contribution guidelines? Thanks

Copy link

hanwen commented Aug 5, 2016

please do it through the contrib guidelines. You can assign the review to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

3 participants