OPENSSH KeyReader for more keys

[darinkes]

Add support to parse OpenSSH Keys with ECDSA 256/384/521 and RSA.

Change-Id: Iaa9cce0f2522e5fee377a82cb252f81f0b7cc563

[huobazi]

+1

[xivk]

Anything I can do to help with this pull request? Willing to put in some work, this is something I need.

[jons]

seconded for needing this feature.

[aibars]

Any idea when does a new release including these changes will be released?

[epenet]

@darinkes there is a conflict on the branch. Could you maybe rebase it?

[epenet]

@drieseng is there anything we can do to help getting this merged in?

[drieseng]

@darinkes LGTM, with some comments. Please update README.md as well.

Some other things I'd like to discuss:

KeyHostAlgorithm

To me, either:

• KeyHostAlgorithm remains public, and we update PrivateKeyFile.HostKey to return KeyHostAlgorithm.
  -or-
• We change KeyHostAlgorithm to internal.

IDisposable

In PrivateKeyFile, we currently keep a "copy" of Key around to be able to dispose it.
We could instead implement IDisposable on KeyHostAlgorithm.

Regardless where we dispose the key, we should also check if the key effectively implements IDisposable instead of always casting to IDisposable like we do now. This allows us to remove the dummy IDisposable implementation from EcdsaKey and ED25519Key.

PrivateKeyFile unit tests

Right now, the unit tests for PrivateKeyFile are limited to verifying whether we do not throw an exception when loading a given key format. Shouldn't we verify whether the key information is correctly read, and cover more failure conditions?

[chrduc]

@drieseng @darinkes what is the ETA for your openssh_format_rsa PR? We are wanting this change ASAP

[darinkes]

@drieseng @darinkes what is the ETA for your openssh_format_rsa PR? We are wanting this change ASAP

I hope to have some spare time this weekend to include the comments of @drieseng

[drieseng]

@chrduc Don't forget that we all have day jobs. Consider sponsoring @darinkes and/or SSH.NET to show us your appreciation :p

[chrduc]

@drieseng @darinkes what is the ETA for your openssh_format_rsa PR? We are wanting this change ASAP

I hope to have some spare time this weekend to include the comments of @drieseng

Thanks @darinkes

[darinkes]

Updated the PR with suggestions from @drieseng.
Would be awesome if someone could take this PR for a test-ride.

[darinkes]

@darinkes LGTM, with some comments. Please update README.md as well.

✅

PrivateKeyFile unit tests

Right now, the unit tests for PrivateKeyFile are limited to verifying whether we do not throw an exception when loading a given key format. Shouldn't we verify whether the key information is correctly read, and cover more failure conditions?

I would also like to use new keys on each run instead of hardcoded resources.

[drieseng]

I would also like to use new keys on each run instead of hardcoded resources.

I don't see a problem with the hardcoded resources. They should also allow for predictable results to verify against.
What would the advantage be of using new keys?

[drieseng]

@darinkes Can you have a look at my other comments here?

[drieseng]

Would be awesome if someone could take this PR for a test-ride.

When I have some time, I'll add integrations tests. For now these integration tests are still closed source :(
I should also find time to open source these.

[darinkes]

Some other things I'd like to discuss:

KeyHostAlgorithm

To me, either:

• KeyHostAlgorithm remains public, and we update PrivateKeyFile.HostKey to return KeyHostAlgorithm.
  -or-
• We change KeyHostAlgorithm to internal.

No opinion on that.

IDisposable

In PrivateKeyFile, we currently keep a "copy" of Key around to be able to dispose it.
We could instead implement IDisposable on KeyHostAlgorithm.

Regardless where we dispose the key, we should also check if the key effectively implements IDisposable instead of always casting to IDisposable like we do now. This allows us to remove the dummy IDisposable implementation from EcdsaKey and ED25519Key.

Ack, makes sense.

PrivateKeyFile unit tests

Right now, the unit tests for PrivateKeyFile are limited to verifying whether we do not throw an exception when loading a given key format. Shouldn't we verify whether the key information is correctly read, and cover more failure conditions?

Ack, this should be added as well.

I would also like to use new keys on each run instead of hardcoded resources.

I don't see a problem with the hardcoded resources. They should also allow for predictable results to verify against.
What would the advantage be of using new keys?

My concern is the padding, to ensure its done right hardcoded resources just test it works for those keys.
But maybe just overthinking it.

[drieseng]

@darinkes Thanks, and sorry it took this long.

[darinkes]

@darinkes yay, cool! :) No worries about the timeframe!
Ping me, when you want to start the refactoring.

[NN---]

When can we expect NuGet with the update ?

[michaelstanford]

When can we expect NuGet with the update ?

Is there any update on this?

[alucard87pl]

Any update on this? ShareX depends on this library and it's seriously cramping my productivity.

[alucard87pl]

Since this appears to be merged, when can we expect a new release of SSH.NET?
There are now a few other applications that I am using on a nearly daily basis that make use of this library and I am relegated to using SSH through the command line instead.
Last full release was almost a year ago :(

[lilhoser]

Agreed. Can we please get a new release? I can't use this project due to:
Renci.SshNet.Common.SshException: 'cipher name aes256-ctr for openssh key file is not supported'

[Isitar]

what hinders us from releasing?

[zybexXL]

Unavailable single owner, unwilling to just add others as admins to help things along. Eventually someone else needs to just fork this thing and take a more active stance on the project, this is getting ridiculous. I propose SSHNet+ for the name.

[chrduc]

We forked and fixed this almost a year ago

…

On Tue, 8 Feb 2022 at 8:07 pm, Pedro Fonseca ***@***.***> wrote: Unavailable single owner, unwilling to just add others as moderators to help things along. Eventually someone else needs to just fork this thing and take a more active stance on the project, this is getting ridiculous. I propose SSHNet+ for the name. — Reply to this email directly, view it on GitHub <#614 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB7YJBLTEPFHEZDLT5RXGTLU2DMMVANCNFSM4KGORNPQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were mentioned.Message ID: <sshnet/SSH. ***@***.***>

[zybexXL]

I did the same to merge in 3 or 4 of my own PRs, but if we keep doing that just for our own stuff it doesn't really help the project and the community at large.

[darkoperator]

<!-- /* Font Definitions */ @font-face {font-family:"Cambria Math"; panose-1:2 4 5 3 5 4 6 3 2 4;} @font-face {font-family:Calibri; panose-1:2 15 5 2 2 2 4 3 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; font-size:11.0pt; font-family:"Calibri",sans-serif;} a:link, span.MsoHyperlink {mso-style-priority:99; color:blue; text-decoration:underline;} .MsoChpDefault {mso-style-type:export-only;} @page WordSection1 {size:8.5in 11.0in; margin:1.0in 1.0in 1.0in 1.0in;} div.WordSection1 {page:WordSection1;} -->It is a lot of work specially when someone has kids and main job , even more in COVID times, do understand the frustration from both sides. So Pedro are you going to do the fork and add other maintainers? I personally use the project but lack the skills, time and commitment for such and endeavor, even forking for my own project became a real pain since Open Source is a hobby and I put out stuff as is with 0 implied support. If you do and maintain it more regularly I would use it 😊  Sent from Mail for Windows From: Pedro FonsecaSent: Tuesday, February 8, 2022 5:07 AMTo: sshnet/SSH.NETCc: Carlos Perez; CommentSubject: Re: [sshnet/SSH.NET] OPENSSH KeyReader for more keys (#614) Unavailable single owner, unwilling to just add others as moderators to help things along. Eventually someone else needs to just fork this thing and take a more active stance on the project, this is getting ridiculous. I propose SSHNet+ for the name.—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.Message ID: ***@***.***> 

[zybexXL]

It is a lot of work specially when someone has kids and main job , even more in COVID times, do understand the frustration from both sides. So Pedro are you going to do the fork and add other maintainers? I personally use the project but lack the skills, time and commitment for such and endeavor, even forking for my own project became a real pain since Open Source is a hobby and I put out stuff as is with 0 implied support. If you do and maintain it more regularly I would use it 😊

It is a strong commitment, which I am also reluctant to make. I wouldn't like to start it and then let it fall to the same disrepair due to lack of time. It may seem hypocritical to criticize Gert and then refuse to do what he does, but the difference is that he already made that commitment, I did not. I would be willing to onboard more admins/maintainers though, so I'm still considering if I should go ahead or not. It would be a first time for me as a maintainer of such a public project, and I also need to check with my company if it doesn't break any of their policies. All in all, I feel it would be best if Gert just added some active admins and stop trying to micromanage every single line of code.

[darkoperator]

Yep agree more active admins would be great also some docs on how we can help test so as to push stuff faster.  

[zybexXL]

@darkoperator, please don't reply via email - check the Github page directly and edit your comments there to remove the extra stuff coming from outlook.

[drieseng]

I'd be happy to add new members. That doesn't mean that any change contributed by them would be blindly accepted (the same goes for any change that I would want to make... yes, I can hear you laughing).

Having support for numerous legacy target frameworks slows down the process considerably. I actually have an old Windows 8.1 VM that I need to use for part of the release process. Most of the software that I need to build a release is no longer available for download. I sollicited feedback on this topic through #665, but I haven't even had time to act upon it.

I'd really like to move this project forward, but it's just one of many things I'd like to do. Work has kept me very busy lately (12 to 15 hours a day).

@darkoperator, @darinkes: Would you guys be interested in becoming part of the team? Perhaps more souls in the team will also encourage me to spend more of my (limited) time on SSH.NET.

[IgorMilavec]

@drieseng I'm also willing to help out. There are a lot of PRs pending review, issues to close etc. I think with proper "rules of engagement" you can still keep the oversight of the project while letting others help out.
One other area I feel should be enhanced is a release pipeline to automatically publish the beta NuGet package when a commit is made to the develop branch.

[darkoperator]

not a C# expert but willing to help where I can :)

[darinkes]

@drieseng sure! trying to support the stuff i've added anyways :)

[WojciechNagorski]

Version 2023.0.0 has been published https://www.nuget.org/packages/SSH.NET/2023.0.0