| Summary: | Enable runtime loading of GSSAPI libraries | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Portable OpenSSH | Reporter: | Aaron Sowry <aeneby> | ||||
| Component: | Kerberos support | Assignee: | Assigned to nobody <unassigned-bugs> | ||||
| Status: | CLOSED WONTFIX | ||||||
| Severity: | enhancement | CC: | aeneby, djm | ||||
| Priority: | P5 | ||||||
| Version: | -current | ||||||
| Hardware: | Other | ||||||
| OS: | Linux | ||||||
| Attachments: |
|
||||||
Thanks - this is a nice idea, but we aren't interested in supporting run-time loading of libraries inside OpenSSH. There are a number of potential problems that concern us, including figuring out the library name on multiple platforms (your patch hardcodes one, but there will be others), binary incompatibility between the headers on the build host and the libraries on the host running sshd, etc. I have some long-term vague plans to factor all the authentication methods out into helper programs. This would seem to solve your particular problem (as well as my primary goal of making the auth code more testable), but it is still a fair way away. Close all resolved bugs after 7.3p1 release |
Created attachment 2301 [details] Patch to enable runtime loading of GSSAPI libraries Currently, building the ssh client with kerberos enabled means dynamically linking against the GSSAPI library. This results in a somewhat non-portable binary, since it won't run on systems which don't have this library available. The attached patch implements runtime loading of the GSSAPI library, allowing fallback to alternative authentication mechanisms if the library can't be found. Diff is against today's CVS.