Here''s a patch that adds support for an :authentications option like the ssh client PreferredAuthentications option. It allows the user to specify which kinds of authentications to try and in which order. -- Daniel Hobe <daniel@nightrunner.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: pref_auth.patch Type: application/octet-stream Size: 3711 bytes Desc: not available Url : http://rubyforge.org/pipermail/net-ssh-devel/attachments/20040728/27ebf6dd/pref_auth.obj
Daniel Hobe wrote:> Here''s a patch that adds support for an :authentications option like the ssh client > PreferredAuthentications option. It allows the user to specify which kinds of > authentications to try and in which order.Nice, thank-you Daniel--this is a great idea. I look forward to adding host-based authentication. :) However, I have a few questions: 1) Nit-pick: what if we called it authentication_methods or auth_methods, instead of authentications? 2) I hesitate to put the array of authentication methods in the transport session, since the transport layer doesn''t have anything to do with authentication. What if the SSH::Session kept it, and passed it to the UserAuth class when it gets instantiated? (Kind of like how the :keys option is handled?) On another note: the rb-keygen utility has been checked into CVS, in a new ''bin'' subdirectory. It implements a subset of the ssh-keygen functionality. -- Jamis Buck jgb3@email.byu.edu http://www.jamisbuck.org/jamis "I use octal until I get to 8, and then I switch to decimal."
Jamis Buck wrote:> Daniel Hobe wrote: > >> Here''s a patch that adds support for an :authentications option like >> the ssh client >> PreferredAuthentications option. It allows the user to specify which >> kinds of >> authentications to try and in which order. > > > Nice, thank-you Daniel--this is a great idea. I look forward to adding > host-based authentication. :) However, I have a few questions:I also think GSSAPI might be good to add. I have no idea how difficult this would be, but would give support for Kerberos, which would be nice (at least for me :)> 1) Nit-pick: what if we called it authentication_methods or > auth_methods, instead of authentications?sure, auth_methods is short and sweet.> > 2) I hesitate to put the array of authentication methods in the > transport session, since the transport layer doesn''t have anything to do > with authentication. What if the SSH::Session kept it, and passed it to > the UserAuth class when it gets instantiated? (Kind of like how the > :keys option is handled?)Sounds good.> > > On another note: the rb-keygen utility has been checked into CVS, in a > new ''bin'' subdirectory. It implements a subset of the ssh-keygen > functionality. >I''ll take a gander at it.
Daniel Hobe wrote:> Jamis Buck wrote: > >> Daniel Hobe wrote: >> >>> Here''s a patch that adds support for an :authentications option like >>> the ssh client >>> PreferredAuthentications option. It allows the user to specify which >>> kinds of >>> authentications to try and in which order. >> >> >> >> Nice, thank-you Daniel--this is a great idea. I look forward to adding >> host-based authentication. :) However, I have a few questions: > > > I also think GSSAPI might be good to add. I have no idea how difficult > this would be, but would give support for Kerberos, which would be nice > (at least for me :)That *would* be nice. :) One of us should take a peek at the OpenSSH sources sometime to see how they''ve implemented that.> >> 1) Nit-pick: what if we called it authentication_methods or >> auth_methods, instead of authentications? > > > sure, auth_methods is short and sweet. > >> >> 2) I hesitate to put the array of authentication methods in the >> transport session, since the transport layer doesn''t have anything to >> do with authentication. What if the SSH::Session kept it, and passed >> it to the UserAuth class when it gets instantiated? (Kind of like how >> the :keys option is handled?) > > > Sounds good.K. The auth_methods stuff is now in CVS, and it seems to be working. Right now I''m raising an exception if an unknown authentication method is given, but perhaps they should just be silently ignored? Any opinions? On another note: I''ll be out of town for a week-and-a-half, starting Friday. I think there are enough improvements for another release, say 0.0.5. Any thoughts? Any last-minute feature additions? -- Jamis Buck jgb3@email.byu.edu http://www.jamisbuck.org/jamis "I use octal until I get to 8, and then I switch to decimal."
Jamis Buck wrote:> Daniel Hobe wrote: > >> Jamis Buck wrote: >> >>> Daniel Hobe wrote: >>> >>>> Here''s a patch that adds support for an :authentications option like >>>> the ssh client >>>> PreferredAuthentications option. It allows the user to specify >>>> which kinds of >>>> authentications to try and in which order. >>> >>> >>> >>> >>> Nice, thank-you Daniel--this is a great idea. I look forward to >>> adding host-based authentication. :) However, I have a few questions: >> >> >> >> I also think GSSAPI might be good to add. I have no idea how >> difficult this would be, but would give support for Kerberos, which >> would be nice (at least for me :) > > > That *would* be nice. :) One of us should take a peek at the OpenSSH > sources sometime to see how they''ve implemented that. > >> >>> 1) Nit-pick: what if we called it authentication_methods or >>> auth_methods, instead of authentications? >> >> >> >> sure, auth_methods is short and sweet. >> >>> >>> 2) I hesitate to put the array of authentication methods in the >>> transport session, since the transport layer doesn''t have anything to >>> do with authentication. What if the SSH::Session kept it, and passed >>> it to the UserAuth class when it gets instantiated? (Kind of like how >>> the :keys option is handled?) >> >> >> >> Sounds good. > > > K. The auth_methods stuff is now in CVS, and it seems to be working. > Right now I''m raising an exception if an unknown authentication method > is given, but perhaps they should just be silently ignored? Any opinions?Raising an exception is fine. Perhaps you could log it and move on.> On another note: I''ll be out of town for a week-and-a-half, starting > Friday. I think there are enough improvements for another release, say > 0.0.5. Any thoughts? Any last-minute feature additions? >No new stuff that I can think of, ship it!