HN Explorer

13 comments

[ 2.5 ms ] story [ 41.5 ms ] thread
neilsimp1
I wonder how this compares with https://github.com/PowerShell/Win32-OpenSSH feature and stability-wise.
nailer
Compared to OpenSSH for Windows:

- They're both native Windows apps - no Cygwin etc. OpenSSH is C, Pyrexecd is Python.

- OpenSSH has a service, Pyrexecd is a system tray app (despite the 'd' in the name)

- OpenSSH launches the normal shell, Pyerexecd launches cmd

- Pyrexecd shows popups for incoming connections, OpenSSH doesn't have this feature.

- Pyrexecd is for single users.

Honestly it's hard to compete with Microsoft's OpenSSH port (particularly if the plan to merge it into the mainline OpenSSH code happens).

It's cool code though - Python on Windows doing SSH stuff is useful as a systems management tool outside of this.

kodablah
For reference, the work is done at https://github.com/PowerShell/openssh-portable even though the wiki, issues, etc happen there.

I will say, from my limited experience w/ MS's fork, they take a bit of a hacky approach. For instance, I just wanted standalone sshd, but they really want you to run it as a service and install/uninstall with PowerShell scripts [0].

In general though, the open SSH fork seems to support pluggable shells and has decent pty support (it fires up a separate shellhost.exe process per client)

0 - https://github.com/PowerShell/Win32-OpenSSH/issues/909#issue...

nailer
This is an interesting perspective. I run sshd on nix through sysvinit or systemd, running it as a Windows service seems expected rather than 'hacky'. If you just ran sshd as an executable it would still be attached to the controlling terminal on a nix box.

Likewise sshd is typically deployed via a package manager that calls Bourne shell or bash, posh seems a reasonable equivalent. What would you use instead?

kodablah
It should work both ways.

I have run sshd locally w/ an sshd_config and I would expect that I can run it standalone. My project was to do a self-contained ssh-over-tor setup. So I could have an sshd_config like so:

    Port 5678
    HostKey /home/myuser/sometempdir/ssh_host_rsa_key
    HostKey /home/myuser/sometempdir/ssh_host_dsa_key
    HostKey /home/myuser/sometempdir/ssh_host_ecdsa_key
    HostKey /home/myuser/sometempdir/ssh_host_ed25519_key
    PidFile /home/myuser/sometempdir/sshd.pid
    UsePam yes
And run this:

    /usr/sbin/sshd -f /home/myuser/sometempdir/sshd_config -E /home/myuser/sometempdir/sshd.log
Whether I run this manually, as a service daemon on the part of the OS, etc should not affect the core piece. For my project, I even considered going as far as statically linking Open SSH and Tor, but never completed it.
orliesaurus
You misspelled syntax in the readme 'sytax', other than that it looks good. Nice!
j_s
Thanks for sharing this project. I've gotten more than my $100 worth out of my purchase of https://www.bitvise.com/ssh-server back before OpenSSH supported multi-factor authentication (key + password). It is now free for personal use, and combined with its client app makes tunneling/securing Remote Desktop a breeze.

Is there anything popular written in Go that supports Windows on purpose? When securing remote access I prefer to follow the wisdom of the crowds. The closest I've found most recently mentions success via the Windows Subsystem for Linux:

https://github.com/gravitational/teleport/issues/481

ethanpil
Can someone give me some use cases for this?
bradenb
Aren't the use cases are the same as for any SSH server?
euske
It's useful when you have a Windows and Unix box side-by-side. I often develop a Windows app on Unix (either VM or real machine), and wanted to run a command on the target machine remotely. Initially this was meant to be only run on an internal network (without auth) but then I added a SSH interface because it's just the standard.
0x0
One worry that is always on my mind when using ssl/ssh implementations outside the beaten path is that it's hard to know if the crypto is done right. For other types of software it's easy to tell if something is broken - things crash visibly. But with crypto, things may appear to work and interoperate correctly - but there could still be a fatal invisible flaw such that everything becomes trivially decryptable or accepts authentication with trivially fakeable key pairs, and so on. Not only do you have to make it work, you have to make it flawless in the invisible. I'm not picking on this project in particular - it could be excellent for all I know - but it's always a nagging concern...
euske
I can get that. This relies on another Python package which does all the SSH stuff, and they seem to be well maintained. But I'd still say you have to be careful when you try this wild.
moondev
You can also very easily run sshd on widows with WSL