Live data from Hacker News

Looking Forward: Support for Secure Shell

blogs.msdn.com

91–100 of 404 posts

Re: Looking Forward: Support for Secure Shell

#91

Hallelujah... new package manager, modular install, and now ssh? What's left? Perhaps a real terminal? To bad this won't make it into Win 10, unless I misunderstood something. Looks like my days of sneering at Windows as a toy are numbered... end of an era, and it makes me a bit sad, sniff .

Well, Win10 is the 'last Windows' according to MS, so this will probably arrive as an update later.

If this is like "OS X", then it doesn't mean anything. You'll still have to pay to buy "Windows 10.1" or "Windows 10 Redstone" or whatever they will call it.

"Last version of Windows" is nothing but marketing, just like the overhyped "one Windows" idea. There isn't actually just "one" Windows 10, is there?

Most versions of Windows 10 are not even within 10% of each other in terms of differences. There's a much larger gap between them. Windows 10 IoT Core isn't actually Windows 10, just like Brillo isn't actually Android.

Re: Looking Forward: Support for Secure Shell

#92

I happily await the day when I no longer need to install PuTTY on all of my fresh Windows installs.

They really need to announce a conhost replacement. The "experiments" in Windows 10 are undeniably improvements for when we still use things like cmd, but Powershell needs a modern terminal window and there needs to be a native answer to Putty for both SSH and Powershell remoting. I'd say after SSH this should be a priority for the Powershell team. Conhost is holding them back. A lot.

Try ConEmu, it's a very good terminal window.

Re: Looking Forward: Support for Secure Shell

#93

This would be great if they implement an SSH server, but I'm guessing the shell it connects to is PowerShell, rather than a sh derivative, so many tools many not work with it?

It wouldn't be much different than, say, Cisco switches/routers, which (IIRC) also are managed over SSH but implement an atypical shell oriented around network configuration.

So yeah, most tools would need to be adapted to manage Windows. A first-party Cygwin equivalent would be a good next step to ease that particular pain point, but said pain point is much easier than, say, having to install an SSH server yourself.

Re: Looking Forward: Support for Secure Shell

#94

Earlier quoted context omitted.

In a recent HN thread, someone pointed me to MobaXterm ( http://mobaxterm.mobatek.net/ ) and I have gladly deleted PuTTY.

Do you know if it has support for using an external text editor instead of the one they provide?

you can launch any editor from their command line like: ➤ ../../drives/c/Program\ Files\ \(x86\)/Notepad++/notepad++.exe

Re: Looking Forward: Support for Secure Shell

#95
post #86

Earlier quoted context omitted.

Cygwin has all of those things and ssh server support.

Fair. But I couldn't target my crappy roguelikes at cygwin - requires complicated third-party installs. I ran cygwin-with-ssh heavily for a while in 2003. It was a hell of a thing to get it going. Then I had trouble getting it to work on a new computer and gave up. Shouldn't be surprised that it got good again.

Try Babun [1] for a pre-configured Cygwin setup with an easy install. I've been using it for the past month or so and it works great.

[1]: http://babun.github.io/

Re: Looking Forward: Support for Secure Shell

#96

Earlier quoted context omitted.

Well, Win10 is the 'last Windows' according to MS, so this will probably arrive as an update later.

If this is like "OS X", then it doesn't mean anything. You'll still have to pay to buy "Windows 10.1" or "Windows 10 Redstone" or whatever they will call it. "Last version of Windows" is nothing but marketing, just like the overhyped "one Windows" idea. There isn't actually just "one" Windows 10, is there? Most versions of Windows 10 are not even within 10% of each other in terms of differences. There's a much larger…

OS X updates are free. I have installed a few since getting my Mac.

Re: Looking Forward: Support for Secure Shell

#97
post #57
post #40

Earlier quoted context omitted.

the code for the VPN is better because...?

It's not necessarily better. But now you have two layers of security (VPN + SSH), rather than just one. And as others have mentioned, either way it's still good practice to disable password auth, so that you can only connect to SSH using a public/private keypair.

If there is a defect with VPN and you gain arbitrary execution then you'd have access on the system as whatever user the VPN was running as. You don't necessarily have to break VPN and SSH.

Re: Looking Forward: Support for Secure Shell

#99

Earlier quoted context omitted.

How would we know unless we can read (and compile) the source code?

Considering how few people read and compile the Linux source code, how do you know on Linux? Most distributions are binary, not source.

I'm not sure about reading, but several distributions (notably, Gentoo and Slackware) encourage (and in the former case, require) users to configure and compile Linux from source instead of relying on a binary installation.

Of course, this doesn't do anything against a malicious install environment or a backdoored compiler, but it's a start.

Re: Looking Forward: Support for Secure Shell

#100

Wonderful. I am a big supporter of Powershell, and while Powershell has supported remoting since almost day one, it will never enjoy quite as much support as SSH already receives (e.g. third party tools, firewall support, etc). It is also nice that they're looking into using something fairly "proven" secure, OpenSSH is exposed to the internet a lot (even if, yes, that is not best practice) so we can reasonably expect…

SYSLOG! For the love of god, please support syslog! I work as a consultant supporting a SIEM, and the amount of hoops we need to jump through to get logs from Windows servers is crazy compared to changing one line in a syslog.conf file. I actually dread when a client says "we're an all Windows environment" because wow initial setup just got that much harder. And if we want to install a syslog forwarder on their domai…

You CAN export the event log data of course, even remotely. But it's rather ugly and I agree that some standard aggregation (syslog or anything) would be great.
Post reply on HN