Running SSH on Windows
solutious.com
solutious.com
I was just about to write a rant about how insane it is that windows people try so hard to run things that look "native" (with GUIs and buttons and stuff) instead of simply running the original software in its natural environment (openssh under cygwin, in this case). For security-sensitive software especially, that's a huge problem.
But then I clicked through the link to the "copssh" page:
http://www.itefix.no/i2/node/27
And that's exactly what it is: a custom installer around a minimal cygwin/openssh distro.
So, bravo, I guess. But that's the link you should be reading, not the one from the original author who doesn't seem to understand what the software is actually doing, and would prefer to write tutorials with pretty screenshots instead.
I'm not sure what you mean when you say I "don't seem to understand what the software is actually doing". Could you elaborate?
But the criticism was basically one of misplaced audience. As a guide for a typical windows-only IT wonk to install an sshd, it's really not bad. But I like to believe (or at least pretend) that a typical HN reader is a little above that level. To folks here, the critical information is that (1) openssh works under cygwin and (2) there's a simple installable distro for it. That information is conveyed just fine by the link to the upstream package, without the need for a tutorial.
Add that to the fact setting up a remote access (!) mechanism on a host is an inherently security-critical operation that requires a clear low-level understanding of the software (i.e. more than can be taught with screenshots), and I guess I got a little cranky.
Running an SSH server was a quick solution for automating some basic tasks in Windows. Incidentally, I had a great conversation today with a Windows guy and I'll probably look further into solving these problems with Powershell.
I don't think most Windows users care about looking native, it's more being native (and I don't understand why you put that word in quotes, Win32 / Unix are different APIs). Ie:
* Using Win32 services that your existing tool that monitors Win32 services works for (although you can hack this yourself for Cygwin).
* Logging to the event log, with all the existing filtering and remoting your other apps are using.
* Firing up a object shell with cmdlets for Windows administration rather than a regex-focused one focused on Unix commands.
* APIs available for languages you know, rather than ones you don't.
Imaging someone gave you a Windows app, to run via wine on Unix, that:
* lacked an initscript
* couldn't speak to syslog
* had documentation that assumed you were running powershell, not bash.
* Lacked a Python/Java/C API and provided a .net one instead.
and then ranted about how insane Unix people try so hard to run things that 'look native'.
PS - I'm a Unix guy. But for Windows, I'd use /n software Powershell server. It's a real SSH server for Windows, not someone's MSI wrapped around OpenSSH.
That said, if there was a real Win32 OpenSSH in the future, I'd probably switch to that.