yeah, never too late i guess? it took more than a decade to make such a move...
Looking Forward: Support for Secure Shell
121–130 of 404 posts
Re: Looking Forward: Support for Secure Shell
#122Earlier quoted context omitted.
> In general people really are starting to run out of reasons to "hate" Microsoft. It will be interesting to see what they come up with in the future... I agree with you overall, MS has made GREAT strides in the last year towards moving my needle from "Wouldn't touch if my life depended on it" to "Huh, that's actually pretty interesting". The old MS still shows through with things like how they are handling Win 10 (B…
> how they are handling Win 10 (Both in versions and cost) I'm a bit confused by this. It's free for any genuine Windows 7 or 8 user, and $99 to $199 for anyone else. There are two SKUs (Home and Pro), rather than the multitude with XP or Vista. How is this not a reasonable approach? Especially since Windows 10 is supposed to be the last Windows release of this kind.
> It's free for any genuine Windows 7 or 8 user, and $99 to $199 for anyone else.
It's free ONLY if you get it in their window (1 year I think) it just seems unnecessarily complicated when they should just make it free. Also they have 3-4 more SKUs than just Home and Pro (which really should only be 1).
> Windows 10 is supposed to be the last Windows release of this kind
I'll believe that when I see it also there is nothing I've seen so far to imply all further updates would be free.
Re: Looking Forward: Support for Secure Shell
#123http://www.microsoft.com/en-us/download/details.aspx?id=2391 If I am forced to use Windows in an Enterprise setting, then I just go to Control Panel and enable the POSIX layer ("SUA"), then download the SDK and install. With some minor changes to the %Path, it just works. SUA has older versions of tcsh, ksh, vi and many other utilities, including an older Perl and an old GCC toolchain that does work. It is 4.2BSD bas…
Afaik SUA is pretty much dead, so do not carry too much hope in seeing improvements for it.
Re: Looking Forward: Support for Secure Shell
#124I made an uncomfortably audible gasp of shock upon seeing this. Server versions of Windows have been heading in a console-only direction for a while now but the complexity of PowerShell remoting really didn't make it feel like a feasible solution.
This completely changes the windows admin game.
Re: Looking Forward: Support for Secure Shell
#125Earlier quoted context omitted.
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.
Yes, and that's why so few people use those distributions.
Re: Looking Forward: Support for Secure Shell
#126Earlier quoted context omitted.
> how they are handling Win 10 (Both in versions and cost) I'm a bit confused by this. It's free for any genuine Windows 7 or 8 user, and $99 to $199 for anyone else. There are two SKUs (Home and Pro), rather than the multitude with XP or Vista. How is this not a reasonable approach? Especially since Windows 10 is supposed to be the last Windows release of this kind.
I believe they also have Windows 10 Enterprise, Windows 10 education and if we include the phone OS: Windows 10 mobile and Windows 10 mobile enterprise.
Enterprise is understandable - businesses may prefer not to use Pro. I don't believe that you can count Windows 10 Mobile/Mobile Enterprise against the count as they are merely part of Microsoft's effort to combine all their platforms under one operating system.
Re: Looking Forward: Support for Secure Shell
#127Earlier quoted context omitted.
I would suggest you go look at iTerm2, because an example is worth all the words in the world. tmux integration, multiple panes in a window as well as tabs, easy buffer search, instant startup, everything. A shell host should open and do its absolute utmost to get out of my way. ISE does not do this. It's just...it's what I expect 2008 Microsoft to think a terminal should be, lacking empathy for me as a user. And may…
Those sound nice-to-have features, but (personally) I don't think the lack of those makes something "super clunky and awkward to use", especially in comparison to standard terminals. Do you think xterm is too super clunky because it lacks all the bells and whistles? I still do not see where the lack of empathy and tastelessness is apparent in ISE.
I don't think xterm is clunky, no. It doesn't try to help me, but it also doesn't get in my way. iTerm2's feature set does not increase the friction of dealing with the shell inside of it. Literally every time I have to open up ISE, I go, "jesus, why the hell is it doing things?". The experience is just straight-up repellent. It's hard to really describe past "I'd rather click a mouse than use this." And that never happens elsewhere.
But anyway, your "nice to haves" are my "it's 2015, I'm not wasting my time with less." Microsoft's got more money than God, they can do something worth the time of day.
Re: Looking Forward: Support for Secure Shell
#128For all Balmer's thing of dancing on a stage and chanting "developers", there was no point under Gates or he at which Microsoft felt like a pro-developer company. That 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…
>Wishlist: tmux, emacs, vi, netcat, shell option for vi-mode, rc-file with preferences, ncurses library, something simpler than curses, zip and unzip
No thankyou. I can certainly understand including SSH support, but I don't want what is pretty much the only remaining viable non-Unix platform to start bundling horribly dated and clunky Unix-like commands and bloated GNU tools.
Re: Looking Forward: Support for Secure Shell
#129Earlier quoted context omitted.
> In general people really are starting to run out of reasons to "hate" Microsoft. It will be interesting to see what they come up with in the future... I agree with you overall, MS has made GREAT strides in the last year towards moving my needle from "Wouldn't touch if my life depended on it" to "Huh, that's actually pretty interesting". The old MS still shows through with things like how they are handling Win 10 (B…
> how they are handling Win 10 (Both in versions and cost) I'm a bit confused by this. It's free for any genuine Windows 7 or 8 user, and $99 to $199 for anyone else. There are two SKUs (Home and Pro), rather than the multitude with XP or Vista. How is this not a reasonable approach? Especially since Windows 10 is supposed to be the last Windows release of this kind.
> There are two SKUs (Home and Pro), rather than the multitude with XP or Vista
Two SKUs, and then a bunch more; whole list currently is: Home, Mobile, Pro, Enterprise, Education, Mobile Enterprise, IoT core. There are also upcoming still unnamed "industrial" SKUs. Oh, and of course MS is going to offer 32 bit versions too.
Also of course there will also be full suite of Windows Server SKUs, because obviously those are completely different from the client OS...
Re: Looking Forward: Support for Secure Shell
#130Earlier 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...?
The reason that no one has given yet is that you can monitor more carefully when you have a VPN. With a VPN, you can follow the bastion model; the VPN server runs only the VPN code and nothing else (with as much crap removed as possible), with a really restrictive SELinux policy, every tiny error logged and forwarded.
So now, since any attack has to be through the bastion, and all bastion errors are looked at by a human (because there should be only a few of them), then you're more likely to notice a breach more quickly because it won't become caught up in your general logs.
It should be noted that it's as easily possible to have the bastion server run an SSH server, and allow SSH access to other servers on your network.