> Leverage Windows crypto api’s instead of OpenSSL/LibreSSL and run as Windows Service
Was wondering about that. I'm surprised the OpenBSD team is accepting the commits - something so fundamental and Windows specific doesn't seem like their kind of thing - but great!
Why would the OpenBSD team not accept the commits? It is just linking to a system library that will always be present on the platform. It's like saying Windows opensource should be forced to use some thrid party filesystem library.
It's cute that there is some kind of VBScript for calling web services, but this line tells me that this document must have been authored by some kind of PowerShell apologist.
I'm surprised the OpenBSD team is accepting the commits
Theo has come a long way since he lost beaucoup bucks by spitting in DARPA's face after taking their money.[1] Now Microsoft and OpenBSD are besties.[2]
The saddest thing to me is that Yandex is on there. Not because they shouldn't be, but because so many American and Western companies are willing to take, take, take, but are unwilling to give back even a little bit.
>I'm surprised the OpenBSD team is accepting the commits
What commits? From the comments you will learn there were no commits and this is a classic embrace and extend. They are hijacking OpenSSL name, and rewriting it to use Microsoft crypto and APIs.
Best way to address POSIX compatibility concerns is implementing a proper POSIX layer in Windows (and not in a half-baked manner like the now deprecated SUA). I can't imagine how it would hurt anybody.
SUA was not half-baked, this is a very, very hard problem. There is a very serious difference in the way POSIX and Windows model a lot of really important OS primitives, from asynchronicity model in signals, to the semantics of syscalls like `fork`. Every process using these primitives on POSIX has specific behavior defined under those primitives, and if you don't choose _exactly_ the right behavior on the POSIX subsystem in Windows you will definitely break programs.
So, no. You can't "just" implement a POSIX subsystem correctly. These systems are just not compatible. It will always be half broken.
Is this not what midipix.org intends to do? Granted, they're nowhere near close to being finished at this point in time, but it would be great to see the project pick up steam in this space.
Will this OpenSSH server be able to run interactive console programs (like cmd.exe or python.exe), or will it be limited to (say) PowerShell?
Windows doesn't have a good API for hosting a console--it's not like Unix, where a pty has a master end and a slave end. Trying to run a console program in mintty.exe (https://github.com/mintty/mintty/issues/56) or Cygwin SSHD fails for this reason. I wrote a tool, winpty, that makes a best-effort attempt to emulate a Unix pty master by scraping the console buffer, but it has some limitations, so I'm not sure Microsoft would want to use it. Maybe they would expand the console API?
I too was very skeptical. Something about posts from "The Powershell Team" about porting sshd makes me deeply cynical that they would get the integration right from a layering perspective, i.e. as if they would make it support powershell and nothing else.
Fortunately this example shows it going straight into cmd and then they invoke powershell as a next step:
C:\Master>ssh.exe -l user@127.0.0.1
user@127.0.0.1's password: **********
Microsoft Windows [Version 10.0.10566]
(c) 2016 Microsoft Corporation. All rights reserved.
user@DEV-10566-829 C:\Users\user>powershell -File -
Never was much of a windows fan, so a (slightly ignorant) question for someone who is a Win admin - can most administrative things nowadays be done via the command line on Windows (like we've been able to do in *nix land) or is there a gap between what can be done via the GUI vs the command line?
New Server features are primarily controllable via PowerShell and now only secondarily expose a bit of control via GUI. So, indeed PowerShell has taken precedence. However, it would be wrong to say that Windows administration is exactly like managing Unix systems. On the contrary, the more one works with it the more one realizes PowerShell is the anti-Bash.
Lacking in the aeons of interface legacy built into standard Unices, you won't find standbys like 'grep' readily available or even easily implemented. Rather, PowerShell is built from the ground up for scripting. While the addition of SSH will certainly be helpful for quickly checking statuses, (and possibly more in the future should readline usability of PowerShell improve) right now most PowerShell interactions happen via scripting from a local workstation or web or application inputs rather than directly via the interactive shell.
Microsoft are pushing the command line to the point that:
a) Many operations in newer bits of Windows have simple-mode available in the GUI, but more sophisticated options must be scripted. StorageSpaces has a few examples of this, where some of the options around tiered storage, SSD caching, and the layout of pools can only be accessed via posh.
b) Microsoft are pushing completely headless versions of Windows Server for 2016.
Yep. Recent windows servers even default to boot straight to console these days, with none of the GUI services running. MS has realized that centralized deployment and maintenance is really useful and is acting accordingly, hence things like openssh for windows.
(From what I've heard from people using them) On the current server versions, PowerShell should allow to do all that the GUI can do. There is a GUI-less version and I think the GUI actually uses PowerShell underneath, so you can look up in a log how the commands look like for something you only knew how to do graphically before.
This is very goddamned awesome. All I hope is I can set the default user shell for my account. I already use msys2's zsh for my shell (because I use zsh everywhere, on all OS), and being able to ssh into my Windows machine 'normally' (for me, anyways) would be extremely useful.
And this gem: "SSH daemon needs to run as System to support key-based authentication".
Which means, either use weak authentication, or run the daemon as system. I don't even understand why, it's not like the public keys are particularly sensitive (certainly much less sensitive than being able to check passwords for validity)?
Have you checked what user OpenSSH usually runs as on a linux machine in order to allow key-based authentication? I'll give you a hint: it's root. That's no different than running as SYSTEM on Windows.
That is the crux of it. Windows is not going to fundamentally change its authentication system to work around SSH. It's going to feel "hacky" compared to SSH on *NIX (also console interactivity). You'll still need to run Windows updates as a scheduled task as the system user because remote connections have a remote token and the Window Update API blocks such connections...
You have to create a god damn scheduled task to do Windows Updates over WinRM. And it takes ages for Powershell to realise the task is running, and polling the status of the job is a PITA.
Took me days to automate Windows 2012 with Packer. Ugh
I'm interested in how this is going to work in PowerShell with the way everything works now, if there happen to be any details about that (whether here, somewhere else, or a past link)?
I don't know anything about PowerShell, but I have a similar question, I think: how is this going to work? Will I be able to do something like this command line (from my *nix machine)?
It's not the best butt it's better than the others. You can always enhance putty features using MTPuTTY http://ttyplus.com/multi-tabbed-putty/ worth trying
I'm a fan of Bitvise SSH for a Windows SSH server; it's been enough to replace Terminal Services when each employee has their own work machine to remote desktop into.
It's nice that Microsoft recognizes the need for this functionality; I wonder how they will approach the potential per-client licensing issues they like to bring up with their server OS's.
A great openssh for windows for the time being. Being using this and it is great, only thing is not able to do powershell from it once connected to host.
I have had really good luck with this open source, native windows, ssh server.
http://www.kpym.com/2/kpym/index.htm
I have no affiliation with the project, i just thought i'd mention that it is a nice alternative i found.
Blargh. Another OSS project that doesn't expose any kind of version control (7zip is the worst offender). I know, gift horse etc etc but it does make it hard to track the history / future of the project.
Also looks like it hasn't been updated since 2011.
Why does this support telnet? Just seems crazy to me. Is it on by default? That would be a violation of any sane security policy pretty much anywhere. Seems like a serious edge case requirement and odd to bundle with SSH. This is like buying a new car but then having the dealer give you a free horse with your purchase.
nailer|10 years ago
Was wondering about that. I'm surprised the OpenBSD team is accepting the commits - something so fundamental and Windows specific doesn't seem like their kind of thing - but great!
PS. If you're coming from a Unix background and interested in learning posh: https://certsimple.com/rosetta-stone
guelo|10 years ago
emmelaich|10 years ago
These patches are going to the portable version - which has always been a separately maintained branch of openssh. e.g. no PAM, no Kerberos ...
daveloyall|10 years ago
I stopped reading this when I got to this part:
--> It's cute that there is some kind of VBScript for calling web services, but this line tells me that this document must have been authored by some kind of PowerShell apologist.Just put none in the `whois` box and move on.
daguava|10 years ago
PhantomGremlin|10 years ago
Theo has come a long way since he lost beaucoup bucks by spitting in DARPA's face after taking their money.[1] Now Microsoft and OpenBSD are besties.[2]
There are a few companies that give money to OpenBSD. Far too few, but there are some: http://www.openbsdfoundation.org/contributors.html
The saddest thing to me is that Yandex is on there. Not because they shouldn't be, but because so many American and Western companies are willing to take, take, take, but are unwilling to give back even a little bit.
[1] http://www.computerworld.com/article/2580728/security0/darpa... [2] http://www.theregister.co.uk/2015/07/08/microsoft_donates_to...
rasz_pl|10 years ago
What commits? From the comments you will learn there were no commits and this is a classic embrace and extend. They are hijacking OpenSSL name, and rewriting it to use Microsoft crypto and APIs.
kasabali|10 years ago
Best way to address POSIX compatibility concerns is implementing a proper POSIX layer in Windows (and not in a half-baked manner like the now deprecated SUA). I can't imagine how it would hurt anybody.
antics|10 years ago
So, no. You can't "just" implement a POSIX subsystem correctly. These systems are just not compatible. It will always be half broken.
ThatGeoGuy|10 years ago
to3m|10 years ago
unknown|10 years ago
[deleted]
unexistance|10 years ago
togusa|10 years ago
ryanprichard|10 years ago
Windows doesn't have a good API for hosting a console--it's not like Unix, where a pty has a master end and a slave end. Trying to run a console program in mintty.exe (https://github.com/mintty/mintty/issues/56) or Cygwin SSHD fails for this reason. I wrote a tool, winpty, that makes a best-effort attempt to emulate a Unix pty master by scraping the console buffer, but it has some limitations, so I'm not sure Microsoft would want to use it. Maybe they would expand the console API?
asveikau|10 years ago
Fortunately this example shows it going straight into cmd and then they invoke powershell as a next step:
- https://github.com/PowerShell/Win32-OpenSSH/wiki/ssh.exe-exa...That gives me some hope that it's being done right.
toyg|10 years ago
I would think so. Anything less would not be a real SSH server.
martin1975|10 years ago
tammer|10 years ago
New Server features are primarily controllable via PowerShell and now only secondarily expose a bit of control via GUI. So, indeed PowerShell has taken precedence. However, it would be wrong to say that Windows administration is exactly like managing Unix systems. On the contrary, the more one works with it the more one realizes PowerShell is the anti-Bash.
Lacking in the aeons of interface legacy built into standard Unices, you won't find standbys like 'grep' readily available or even easily implemented. Rather, PowerShell is built from the ground up for scripting. While the addition of SSH will certainly be helpful for quickly checking statuses, (and possibly more in the future should readline usability of PowerShell improve) right now most PowerShell interactions happen via scripting from a local workstation or web or application inputs rather than directly via the interactive shell.
rodgerd|10 years ago
a) Many operations in newer bits of Windows have simple-mode available in the GUI, but more sophisticated options must be scripted. StorageSpaces has a few examples of this, where some of the options around tiered storage, SSD caching, and the layout of pools can only be accessed via posh.
b) Microsoft are pushing completely headless versions of Windows Server for 2016.
Sanddancer|10 years ago
detaro|10 years ago
DiabloD3|10 years ago
mavhc|10 years ago
epistasis|10 years ago
mhurron|10 years ago
e12e|10 years ago
https://github.com/PowerShell/Win32-OpenSSH/wiki/Deploy-Win3...
"If you need key-based authentication:
Install key-auth package
run setup-ssh-lsa.cmd
reboot"
Reboot?
And this gem: "SSH daemon needs to run as System to support key-based authentication".
Which means, either use weak authentication, or run the daemon as system. I don't even understand why, it's not like the public keys are particularly sensitive (certainly much less sensitive than being able to check passwords for validity)?
kohenkatz|10 years ago
Asmod4n|10 years ago
switch007|10 years ago
csours|10 years ago
http://english.stackexchange.com/questions/45136/difference-...
alpb|10 years ago
gionn|10 years ago
switch007|10 years ago
Took me days to automate Windows 2012 with Packer. Ugh
togusa|10 years ago
Also I had to up the memory ceiling on WinRM to 800Mb (WTF!) to even get it to complete.
scott_karana|10 years ago
cakes|10 years ago
daveloyall|10 years ago
andrewstuart|10 years ago
teh_klev|10 years ago
http://mobaxterm.mobatek.net/
I don't work for them, I just think it's a nice tool, so much so I paid for the Pro version.
8draco8|10 years ago
hetman|10 years ago
int_handler|10 years ago
I might be overly nitpicky, but holy inconsistent coding styles Batman: compare https://github.com/PowerShell/Win32-OpenSSH/blob/bafc1df7c5c... to the other source files.
lukeh|10 years ago
doxcf434|10 years ago
ams6110|10 years ago
j_s|10 years ago
It's nice that Microsoft recognizes the need for this functionality; I wonder how they will approach the potential per-client licensing issues they like to bring up with their server OS's.
https://www.bitvise.com/ssh-server
angersock|10 years ago
EDIT: I misread this and though it was only a client. Geez. If it's a server, then of course it should be a service.
duskwuff|10 years ago
daveloyall|10 years ago
charonn0|10 years ago
barkingcat|10 years ago
rm1999|10 years ago
http://www.mls-software.com/opensshd.html#botpage
phippsbrad|10 years ago
voltagex_|10 years ago
Also looks like it hasn't been updated since 2011.
drzaiusapelord|10 years ago
callesgg|10 years ago
jamiesonbecker|10 years ago
(disclaimer: I work there.)
voltagex_|10 years ago
unknown|10 years ago
[deleted]
meneses|10 years ago
unknown|10 years ago
[deleted]
unknown|10 years ago
[deleted]
int_handler|10 years ago
[deleted]
switch007|10 years ago