Live data from Hacker News

Looking Forward: Support for Secure Shell

blogs.msdn.com

331–340 of 404 posts

Re: Looking Forward: Support for Secure Shell

#331

Earlier quoted context omitted.

Yeah every 2 days I have to reboot all of our kit to apply updates... http://i.imgur.com/5ZxiLGf.png

Neglecting security is not a virtue.

Pragmatism is.

This is a Hyper-V hypervisor host on a private VLAN three layers behind the internet and two layers behind the users locked in a room with no console access other than via an ILO card on yet another VLAN.

There has only been one KB which infers a security problem and that has had alternative mitigation put in place.

Not rebooting your server doesn't imply incompetence or disregard to security.

Re: Looking Forward: Support for Secure Shell

#332

Earlier quoted context omitted.

that's a pretty terrible practice no matter what OS you're using.

Why? I assume that "private VLAN" means it isn't exposed to potential external attack.

It must be great to know no-one within your environment will ever do anything wrong. Or download anything that will do anything wrong. Or visit any websites than can hijack your browser into doing anything wrong.

Re: Looking Forward: Support for Secure Shell

#333
post #319

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…

Why is SFTP > FTPS? Any place I could look for some info on this? Are you talking about firewall easy-to-setup?

SFTP is file transfer over ssh. FTPS is FTP over SSL.

FTPS being FTP-based, and FTP being a terrible protocol, SFTP > FTPS definitely. You get all the advantages and security of SSH with SFTP.

Re: Looking Forward: Support for Secure Shell

#334

Earlier quoted context omitted.

I think homebrew and MacPorts are niche though. Your "normal" OSX user wouldn't install them. Heck, I ran Linux for years and years and I haven't even installed them under OSX because if I wanted to run BSD or Linux, I'd have installed BSD or Linux. It's like installing all those GNU tools on Windows to make it more like Linux, and putting Homebrew etc. on OSX to make it more like Linux. Why not just use Linux or BSD…

I think the key point here is this: you're right that regular users don't need homebrew; developers certainly do. By having an analog of homebrew for Windows, Microsoft can attract more developers, which then would translate into a better app infrastructure for Windows. This would then clearly benefit regular users as well. I haven't used Windows in a very long time, but whenever I sit by a friend's computer, I find…

I think that's their long-term strategy. Attract more devs to the platform, new applications will follow, then finally customers.

I'm definitely paying attention.

Re: Looking Forward: Support for Secure Shell

#335
post #319

Earlier quoted context omitted.

Why is SFTP > FTPS? Any place I could look for some info on this? Are you talking about firewall easy-to-setup?

SFTP is file transfer over ssh. FTPS is FTP over SSL. FTPS being FTP-based, and FTP being a terrible protocol, SFTP > FTPS definitely. You get all the advantages and security of SSH with SFTP.

From what I have seen FTPS seems as secure as SFTP if well configured (i.e. no fallback), why do you say FTP is such a bad protocol?

I have tried to look it up, but the answers seem to revolve around firewall being hard to setup and FTP being not secure (which is resolved by encapsuling it in SSL).

Also my search suggests than ssh provides an additional overhead compared to using ssl for file transfer (i.e. http://serverfault.com/questions/131240/ftp-v-s-sftp-v-s-ftp...)

Re: Looking Forward: Support for Secure Shell

#336
post #326

Earlier quoted context omitted.

Couldn't agree more. As a die hard Unix guy and ex Slashdot-esque zealot (colloquially a bit of a twat). Yet I'm knocking out PowerShell all the time now and dread having to log into the pile of CentOS kit I have lying around. It is arcane. Even after 15 years I spend most of my time in the manpages or working out another damn config format. Literally did a two liner to scrape a web page, parse it and call a REST end…

Power shell is ok but MS DOS terminal needs an update: it has several limitations about fonts, encoding and missing libs that make it the worst terminal experience imho. Ah also POSIX compliance could simplify the life of those who develop on Windows. I tryed to develop on Windows for many years, I tryed hard but you are always missing some feature that on Unix is basic.

Name a feature. I've ported tonnes of POSIX stuff to windows. 99% of it's there and the rest is easily plugged into a bit of win32.

I tend to use PowerShell ISE that is built into windows rather than cmd, which you're right, sucks.

Re: Looking Forward: Support for Secure Shell

#337
post #221

Earlier quoted context omitted.

I did find an open source implementation here: http://pash.sourceforge.net/ Don't know if it's any good --- never tried it; it says it's about half complete, but I don't know if it's a useful half. After looking at the docs, you could do a lot of what Powershell does with Unix shells; you'd need a different set of conventions, where instead of using unformatted text as an intermediate format you used a streamable tab…

Isn't this just complaining you want a different tool? The entire Powershell format depends on, amongst other things, the object interface being sane, existing, and usable. The whole point of the GNU system was working around the usual "I can see it here, need this bit, and want to put it there". If you need to do something really specific a lot, you write a tool which does that.

Exactly. The Unix/Linux world has not gone the way of a Powershell type shell for the simple reason that for the uses where we want an object-oriented API, we have a plethora of scripting languages designed for that purpose, and we all have our own favourites.

When we want a text oriented API we use shell scripts. When we want an object oriented API we pick our favourite scripting language - which may very well for many of us be different for different problem domains.

Re: Looking Forward: Support for Secure Shell

#338
post #179
post #128

Earlier quoted context omitted.

>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.

Of that list, I can only see downsides to the middle ones: "emacs, vi, netcat, shell option for vi-mode, rc-file with preferences". Who uses vi-mode in the shell? And Windows already has a boatload of editors. Windows could do a lot better than curses by providing easy means to pop MFC dialogs from the shell to prompt the user. Zip and unzip are already available, in https://pscx.codeplex.com/

> Windows could do a lot better than curses by providing easy means to pop MFC dialogs from the shell to prompt the user.

This was common on the Amiga. E.g. tab completion in the shell can bring up a pre-filtered file requester.

Re: Looking Forward: Support for Secure Shell

#339
post #60

For 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. First, let's have a copy tool with delta-sync support. I can't believe I have to use a cygwin-based rsync to quickly update my backups throughout the day (currently: shut down Virtualbox dev VM, rsync changes, start VM). I understand the MS way to do it is DSFR, but f…

Why not use robocopy?

Re: Looking Forward: Support for Secure Shell

#340

Earlier quoted context omitted.

> Wishlist: tmux, emacs, vi, netcat, shell option for vi-mode, rc-file with preferences, ncurses library, something simpler than curses, zip and unzip. First, let's have a copy tool with delta-sync support. I can't believe I have to use a cygwin-based rsync to quickly update my backups throughout the day (currently: shut down Virtualbox dev VM, rsync changes, start VM). I understand the MS way to do it is DSFR, but f…

Why not use robocopy?

AFAIK robocopy doesn't do delta-sync of file contents, only of a group of files. So if I want to copy a 50GB file where 10MB has changed, it'll still copy the whole 50GB again.

I would love to be wrong.

Post reply on HN