I happily await the day when I no longer need to install PuTTY on all of my fresh Windows installs.
Or worse, Cygwin, because of some obscure process that needs to connect via ssh to your Windows server...
Looking Forward: Support for Secure Shell
51–60 of 404 posts
Re: Looking Forward: Support for Secure Shell
#52I happily await the day when I no longer need to install PuTTY on all of my fresh Windows installs.
Re: Looking Forward: Support for Secure Shell
#53Good news! WinRM is a massive pain. The hoops you have to go through to bootstrap a fresh Windows image to get to the point you can run PowerShell is crazy.
Re: Looking Forward: Support for Secure Shell
#54Earlier quoted context omitted.
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.
Isn't ISE pretty much what you are asking for?
Re: Looking Forward: Support for Secure Shell
#55Earlier quoted context omitted.
It's pretty much a public secret that Ballmer was one of the last reasons why Microsoft did not participate much in the OSS community even though a lot of employees wanted it. To give a concrete example of the changes (heard from a former Microsoft employee): Under Ballmer they were not allowed to touch anything open-source. Pretty soon after he left that was changed to a policy that a BSD/MIT open-source solution mu…
Ballmer has a BAD case of "Not invented here". I remember reading a story about him calling out and mocking an employee in a meeting b/c they has an iPhone (this was around 2008 I think). First off it's a VERY GOOD IDEA to use your competitors products if only to see how they stack up (Spoiler: They blew away MS's mobile offerings in 2008 and still do to this day). Second, what a way to make all of your employees yes…
Still, Steve Jobs was not an easy guy either. I don't know if he would mock an employee for having an Android phone? Not unlikely given how anti-Android he was.
Re: Looking Forward: Support for Secure Shell
#56I happily await the day when I no longer need to install PuTTY on all of my fresh Windows installs.
In a recent HN thread, someone pointed me to MobaXterm ( http://mobaxterm.mobatek.net/ ) and I have gladly deleted PuTTY.
Re: Looking Forward: Support for Secure Shell
#57Earlier quoted context omitted.
A VPN with sshd exposed only inside the private network is a much smarter way of handling remote access. (But it's initially harder, so lots of people don't do it.)
the code for the VPN is better because...?
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.
Re: Looking Forward: Support for Secure Shell
#58Earlier quoted context omitted.
A VPN with sshd exposed only inside the private network is a much smarter way of handling remote access. (But it's initially harder, so lots of people don't do it.)
the code for the VPN is better because...?
Re: Looking Forward: Support for Secure Shell
#59I'm looking forward to MS just dropping their OS entirely and using linux as their back-end. Basically, Microsoft might be better off creating their own linux distribution running a "microsoft windows" windows manager.
And no, epoll isn't enough.
Re: Looking Forward: Support for Secure Shell
#60That has completely changed in the last eighteen months. Each time I think "wouldn't it be cool if" I'm finding a few weeks later that someone at Microsoft is well ahead of me. How much easier it will be to ship my sucky roguelikes to Windows users in this new world!
Hmm. They can now have a path to obsolete cmd. As long as they ship a decent ssh client with the system, users will become accustomed to ssh-ing to their own box instead of using cmd.
Wishlist: tmux, emacs, vi, netcat, shell option for vi-mode, rc-file with preferences, ncurses library, something simpler than curses, zip and unzip. 256 colour is fine, although 24-bit would be impressive. /proc would be cool, but also a big ask I assume. They already have a strong compiler. Make it really easy to find the hex fingerprint required to log on to the sshd-server. Something like inetd could be useful, too.