Creating a chocholatey package for this may increase participation

[jpierson]

Props to the PoweShell team on implementing SSH support for Windows. Following the steps to deploy Win32-OpenSSH was pretty painless however it did require a bit of extra time. Time which could have been saved if there were a chocholatey package available to automate the deployment. I can't guarantee that I would have enough time to set aside to contribute to creating a such package but if there is enough interest this seems like an easy one to create and If time allows I would like to do what I can to make it happen.

[nachfuellbar]

Hi @jpierson chocholatey package seems interesting; i didn't knew this tool are there any real advantages to msi (except updating)? does it work reliable?

[jpierson]

I use it as my primary method of installing software on Windows and I know others that do as well. The only downside is that packages are not always maintained well and chocolatey falls behind due to slow approval process. The main benefit it that makes setting up an environment via scripts or by hand much easier and consistent for the user. The target user is likely to be command line savy which makes chocolatey and ssh a good match.

Install becomes choco install win32-openssh and the download, install, and handling of the package is all taken care of for you. When I come across projects that advertise this type of install I'm more likely to check it out.

[smithian]

I'd be interested in building a chocolatey package for this project. Given the number of changes since the last release, it might make most sense to create both a release package based on the latest zip, plus a nightly build package. is there currently a nightly build, or would that need to be created?

[manojampalam]

We will enable nightly builds by end of February

[jpierson]

I use it as my primary method of installing software on Windows and I know others that do as well. The only downside is that packages are not always maintained well and chocolatey falls behind due to slow approval process. The main benefit it that makes setting up an environment via scripts or by hand much easier and consistent for the user.

On Tue, Dec 1, 2015, 4:49 PM nachfuellbar notifications@github.com wrote:

Hi @jpierson https://github.com/jpierson chocholatey package seems interesting; i didn't knew this tool are there any real advantages to msi (except updating)? does it work reliable?

— Reply to this email directly or view it on GitHub https://github.com/PowerShell/Win32-OpenSSH/issues/42#issuecomment-161106215 .

[factormystic]

I would prefer if this was deployed via powershell package management. Then after adding the package source, users would simply need to run install-package powershell-openssh or whatever the package name is.

[michaeltlombardi]

@factormystic PackageManagement uses Chocolatey as a repository for software. You would be able to install the package either via chocolately itself or via Install-Package.

[factormystic]

You can install Chocolatey as a package source, yes. But you don't need it. So don't do the thing you don't need to do.

[smithian]

I agree with @michaeltlombardi - having a chocolatey package is a good idea even if the recommended installation is through install-package. PackageManagement is still very much under development on Win10. The default repositories included in a vanilla OneGet installation are MSI, MSU, and EXE. you can add Chocolatey, NuGet, and a host of other providers. The one that has the most traction amongst the Ops set is chocolatey, so it would seem to make sense to make one. There's nothing saying that a chocolatey package couldn't coexist with one in another repository.

[war59312]

+1 For Chocholatey

[DarwinJS]

I'd like to do this feature request if no one else is already working it.

[szepeviktor]

The default repositories included in a vanilla OneGet installation are MSI, MSU, and EXE. you can add Chocolatey

It sounds very interesting. https://github.com/OneGet/ChocolateyProvider

[DarwinJS]

The Chocolatey provider is not ready for prod yet. It is broken in Win 10 because the provider code assembly was a 14 old month version. Basically a Microsoft employee bootstrapped the open source project and then it was left up to the community. The folks at Chocolatey have taken up it's development.

However, the PSH 5 provider requires PSH 5 (not trivial for Server 2008 R2 and Win 7 where you have to install PSH 4, reboot and install PSH 5), and does not do much logging (unless this gets upgraded as part of the next release).

In the meantime the native chocolatey client is a light install (folder + environment variable + path tweak) that can be installed from the web with a oneliner and it can service as far back as PowerShell 2.0 (Along with at least .NET 4.0 installed) and works in cmd.exe as well. (it's actually a very similar implementation to Win32-OpenSSH in these regards.

So while the native provider will get there - I'm not sure how long it will be till it has feature parity with the native chocolatey client.

In any case, packaging it in chocolatey will make it available immediately and for when the provider is available.

[DarwinJS]

Is it possible for this project to provide the "current" release also at it's versioned URL? This way I can checksum the files downloaded from the site.

For instance, as of this writing 12_22_2015 is the "current version" and available at https://github.com/PowerShell/Win32-OpenSSH/releases/download/latest/OpenSSH-Win64.zip

However, unliked archived packages, this release is not also available at: https://github.com/PowerShell/Win32-OpenSSH/releases/download/12_22_2015/OpenSSH-Win64.zip

So if I do a check sum on a file I download from the current release for a package for 12_22_2015 - the package will break when you release a new version.

If when a new current version was made available, it was also available at it's versioned URL (https://github.com/PowerShell/Win32-OpenSSH/releases/download/12_22_2015/OpenSSH-Win64.zip) in this case - I could safely checksum the file against that URL even when new versions come out.

I am not saying that the versioned URL location has to replace the "current version" nor even be published - just made available at the same time as current so I can stick my package the version of the package.

When new versions come out I would update the package and upload a new version to Chocolatey.

I hope that makes sense - but let me know if it does not.

[szepeviktor]

AFAIK the latest tag points to another commit than the 12_22_2015 tag: https://github.com/PowerShell/Win32-OpenSSH/tags And there is no OpenSSH-Win*.zip for 12_22_2015.

[DarwinJS]

Yes I understand there is not a versioned zip for 12_22_2015 - I am asking if the team could please adopt the practice of creating one for the current version as soon as that version is also available at "../latest/...", not just as an archive process.

[DarwinJS]

I thought "this should be a nice easy package for a Saturday morning" - should have known it would take longer than expected as soon as I had that thought.

But, the upside is the new chocolatey installer handles

• client tools
• sshd server (with or without key authentication)

For:

• installs
• upgrades and
• uninstalls

And it won't install the server if there is another product with the service "sshd".

It won't be visible on Chocolatey publicly until it makes it all the way through moderation - but you can peek at (or try) the pending package here: [https://chocolatey.org/packages/win32-openssh/2015.12.22]

[jpierson]

Looks like the Chocolatey package as approved by the moderator and went public today! Cheers @DarwinJS!

[manojampalam]

Nice. Thank you @DarwinJS.

[szepeviktor]

Is there an HTML badge for Chocolatey downloads?

[szepeviktor]

Added in #118

[DarwinJS]

I was out yesterday, but able to blog about win32-openssh as well as the chocolatey package here: https://www.linkedin.com/pulse/fastest-way-get-your-hands-new-win32-openssh-darwin-sanoy

[jpierson]

Not sure if it's related or not but I noticed that that after a reboot I was indeed able to use ssh and scp from the standard windows console but PoweShell is now hanging indefinitely for me every time I launch it. Just thought I'd put it out there in case anybody else who has tried the package can verify whether this is an issue or just something wrong on my machine. Note, that in my case I was using a customized powershell profile along with PoshGit and Posh-GVM if that matters.

[DarwinJS]

The package simply extracts the Exes and puts their path on the system path. So it's not likely to be related.
Some thoughts:

• To test whether anything in your profile is causing problems, run "PowerShell -noprofile"
• It may be possible that the binaries are assuming you're running with admin rights so they can write to their own program files folder. This would explain why it might work fine when you installed (you would have given the session admin to do the install) and maybe not later in a session without admin.

[jpierson]

Ok, I think I've narrowed it down to a line in PoshGit's profile.example.ps1 file that get's installed and is made to be called from the user's default profile.

https://github.com/dahlbyk/posh-git/blob/master/profile.example.ps1#L25 Start-SshAgent -Quiet

Commenting out this line seems to work around the issue. At this point I'm not sure whether the issue is with Win32-OpenSSH or with Posh-Git but it seems to be some compatibility issue that should be spelled out regardless. My guess is that anybody also using PoshGit will experience the same issue.

[DarwinJS]

Ohh - that brings up an intersting issue. I wonder if there are any other bad interactions with the built-in git ssh agent?

[dahlbyk]

From https://github.com/dahlbyk/posh-git/issues/258#issuecomment-190531499:

My initial guess is that you're running into PowerShell/Win32-OpenSSH#110 at https://github.com/dahlbyk/posh-git/blob/721089444e2ce9e2bfbcad0b5e0daa5ea8085d66/GitUtils.ps1#L319

posh-git parses ssh-agent output to be able to set environment variables accordingly.