putty support reconsideration?

[mitchcapper]

Previously it was rejected to add paegent support. Code like: https://github.com/dimov-cz/win-sshfs has several good changes. Any plans to re-consider supporting those things? PR could be put together now that it is on GitHub.

[drieseng]

I don't recall having flat out rejected Pageant support. I would prefer packaging it separately from the core SSH.NET library, but that's not to say that it can't live under the SSH.NET "umbrella" and receive the same amount of love and support.

[mitchcapper]

Sure, so there are two options I see(but would be happy to hear of others):

1. Modular auth support then we can make an paegent auth plugin dll, but as SSH.NET is a library something on its own this may not be the best way to go
2. As there are separate projects and we are talking about only adding this feature to the .NET35 build (as I think that's probably the only it would work on) it would be segmented out from the central code as it is. In addition the user would still need to load that agent in with a call so it wouldn't just auto-try paegent auth.

I am happy to put a PR together, in whatever form you would prefer it in but I didn't want to waste time on something that wouldn't be accepted as its already working for my solution (https://github.com/mitchcapper/NovaSFTP2).

[drieseng]

Do you care to elaborate on why you consider the first option "not the best way to go" ?

Thanks!

[mitchcapper]

Well it requires an additional DLL to be generated increasing the requirements for the user to include both (and another nuget package if not bundled in). Its not a big deal but do you want one dll per additional module (not sure if there are any other modules in mind)?. If not just one "Extras" dll? Do you want to define the interface for auth modules or are you find with a PR including that? Do you want the module part of the official repo or just 3rd party maintained?

I don't have strong preferences on any of these things I just want to avoid doing work that is going to be redone so want a strong direction on what you are looking to accept.

[drieseng]

I'd prefer a separate nuget and repo, like I've done for (some of) our crypto stuff. That repo can be part of the sshnet organization, to make it easier to discover and to make it clear that it's the same team providing support for both. Even though I prefer a separate nuget, I'm pretty sure we'll have to release new versions of this nuget package in sync with the main SSH.NET package itself.

I haven't yet checked out your code yet, but I'll definitely want to limit changes to SSH.NET itself to the bare minimum. Once these changes are clearly identified, we can discuss more refactoring or even decide to integrate the authentication module in SSH.NET anyway.

I can't and won't ask for a long term commitment to the SSH.NET project, but I do expect the code to be clear, well-written and - where necessary - documented.

You can start by submitting a PR that defines the interface, but please consider it as a work document. I can't garantee that we won't redo it multiple times.

I'm currently working on finishing the .NET Core support and getting the 2016.0.0 release stable, so I may not be very responsive. Please bear with me :)

[dimov-cz]

Hi,
this is note to the first comment because is not up-to-date. WinSSHFS currently use SSH.NET from here with several changes as submodule and you can find it here: https://github.com/Foreveryone-cz/SSH.NET-for-winsshfs Plan is to rebase often to SSH.NET master branch.

To add pageant support to your custom builds shoud be easy with one cherrypick of this commit:
feo-cz@3471969

[couling]

If I may add a +1 to this. It doesn't really matter to me how it is packaged. But both support for Putty formatted key files and pagent would be really good. Putty formatted keys are [annoyingly] dominant on windows platforms and compatibility is useful. Especially for those users who seek to have a single key per user / machine and not user / machine / application.

This doesn't compile on .NET Core due to lots of missing features.

"Updated" (hacked) the patch here: #536

[shellster]

Going to mention this (develop...kins-dev:develop). For some reason this also got rejected. I think that possibly the best solution would be to roll this patch as a separate library. The main problem is that certain SSH.NET methods and structures are currently too restricted to be accessible. If we could get these marked as public, then this pull could be refactored as an external library. Thoughts @drieseng? Currently I jumped the gun and accepted a pull for pageant support to a SCP plugin for Keepass that is based on this SSH.NET library. At the moment, I'm having to maintain a fork of this library to continue the Pageant support, so I've a vested interest in finding a way to make this work for everyone.

[shellster]

Hey all, is there any buy-in on a path forward for this? I'm happy to help mint a PR if we can get directions from anyone that's part of the SSH.NET team on how they want to approach this. As I mentioned in my previous message, the kins-dev PR opened up access to some SSH.NET internals, but if that is unacceptable, and alternative approach would be to implement more granular hooking of the authentication process in SSH.NET which would potentially allow a lot of similar style solutions in the future. My project which relies on SSH.NET is currently hanging in limbo where I have to pull in copies of SSH.NET and patch and build them for each release, and that really isn't sustainable or smart, long term, so I'm eager for an opportunity to work with the SSH.NET team to figure out how to do this "correctly".

[drieseng]

@shellster As I previously mentioned, I'd first like to see what the minimal interface is that we'd need to expose to allow for Pageant support. My preference remains to ship Pageant support (and other OS or TFM specific functionality) separately from the "core" SSH.NET library.