Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Looking Forward: Support for Secure Shell

blogs.msdn.com

Post reply on HN
Print view View original

211–220 of 404 posts

Re: Looking Forward: Support for Secure Shell

#211

Post by eropple »

baldfat wrote: post #77
tjohns wrote: post #57

Earlier quoted context omitted.

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.

Even better don't use default ports. Or have a second ssh that doesn't except any IP address at port 22 and than have your non-standard port with keys and limited user names and if possible a white list of your IP addresses.

Not using default ports will mildly confuse automated scans and do absolutely nothing to a determined attacker. Or somebody with nmap, which is not the same thing.

If you're whitelisting IPs, you may as well run it on port 22.

Re: Looking Forward: Support for Secure Shell

#212

Post by wumbernang »

jfuhrman wrote: post #207
wumbernang wrote: post #144

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…

>two liner to scrape a web page, parse it and call a REST endpoint with the parsed data as JSON in PowerShell Can you post this 2 liner? Sounds interesting.

I can't post the one-liner as it's earning me a shit ton of cash every month but in concept it's the same as what I've posted here:

https://news.ycombinator.com/item?id=9649090

Re: Looking Forward: Support for Secure Shell

#213

Post by pjc50 »

sudioStudio64 wrote: post #195
freehunter wrote: post #78

Earlier quoted context omitted.

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…

MS has supported event forwarding since 2003. You can set machines to forward events or have them pulled. The events are XML that conform to a published schema. There is a WMI call that call pull the aggregated events off the collection servers. I heard this kind of thing from a vendor the other day. It's like people don't even try to learn how it works. Why are they different? The event log has some transactional gu…

It's like people don't even try to learn how it works

It's much harder to know how it works, for some reason. Information like this doesn't make its way into the community and circulate. On a UNIX system you can poke around /etc and get an idea of the scope of what is configurable. The same is very much not true of the registry and only slightly true of WMI.

Re: Looking Forward: Support for Secure Shell

#214

Post by psykovsky »

pjc50 wrote: post #194
psykovsky wrote: post #190

Earlier quoted context omitted.

Which needs a full desktop environment to be used. Or am I wrong?

It doesn't involve the desktop environment unless you ask it to, and you can invoke it remotely from outside. The system does boot to GUI, but the overhead of that with nobody logged in is not very large. Embedded Windows, on the other hand, is forever the poor relation.

Still no alt+F1 to alt+F7, right? That would be cool to have. I'm really curious, as I made the leap to Ubuntu years ago and the most I've touched windows is doing reinstalls on friends computers.

Re: Looking Forward: Support for Secure Shell

#215

Post by tcfunk »

pjc50 wrote: post #192
halo wrote: post #163

Earlier quoted context omitted.

I'm not even a Powershell fan, I'm just not especially fond of Unix-likes, which feel like a local maximum that has turned into an unchangable standard. I think Unix-like environments feel dated, clunky and there's a tendancy for it to result in permanent bloat, stagnation and a web of interdependencies. I understand that lots of people are familiar with Unix-like tools and their many idiosyncrasies and like to be ab…

Lots of people keep using the word "bloat" to refer to Linux as opposed to Windows, which I find bizarre given that it's long been a criticism in the other direction.

Yeah, I would genuinely like to know what all is considered to be bloat within the Unix space. If anyone could point to some information about this I'd be curious.

Re: Looking Forward: Support for Secure Shell

#216

Post by pjc50 »

ksk wrote: post #182
bad_user wrote: post #161

Earlier quoted context omitted.

I've been historically what can be described a Microsoft hater and I have to tell you, missing official SSH support has never been a hate generator and insinuating otherwise is insulting. The first reason for which I have historically hated Microsoft is because of how they fought open standards. I can't believe that Microsoft changed in any meaningful way when I can't get a Lumia phone or Outlook to work with CalDAV…

If lawsuits and not supporting something you like makes you dislike a company, I'd guess that almost all corporations would be on your 'hate' list. My dislike of MS is quite simple. I simply don't like their products. That doesn't mean I automatically love OSX or Linux. IMO OSX is a mediocre product with a polished user experience and Linux as a desktop is just broken. Unfortunately, I can't say there is a single OS…

I'd guess that almost all corporations would be on your 'hate' list.

This is a popular position, yes. But Microsoft in particular have tried to make Linux impossible on a number of occasions over a period of decades, so it'll take a while for the guerillas to come out of the jungle and stop fighting them.

But now they're in competition with the platform that want to annex all your personal data and the platform that want a veto over all applications, so they're not necessarily the most hated party in the room any more.

Re: Looking Forward: Support for Secure Shell

#217

Post by cturner »

pjc50 wrote: post #179
halo wrote: 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/

    > Who uses vi-mode in the shell?
There's at least a dozen of us. It's my wishlist :)

    > Windows could do a lot better than curses by
    > providing easy means to pop MFC dialogs from
    > the shell to prompt the user.
When you work in an environment with a lot of hosts, Windows is a laborious partner. You need to open remote desktops and click windows to push the OS around. With unix you often have processes that start out being manual, and which gradually get sewn up into automation.

With deliberate effort, you can build automation to Windows platforms. But in unix, one guy with a clue can create vast value working with the defaults. Even on an ancient Solaris box with no compiler or extra tools installed. If you're desperate you'll be able to find a shell that can open a socket server or staple some awk together to get a result.

Windows powershell is a vision of what a shell can be that has grown up separate to the unix world. In a fair world it would be considered heavy-lifting-equipment, like bash or emacs lisp. It would be thriving. But it has lived in a straight-jacket because until now Microsoft has forced operators to to interact with it via the windows GUI.

MFC popups would undermine the benefits of SSH. If you're worried about your shell hanging at a background window event, you'll avoid using it in anger.

Same issue with editors. Existing editors require the GUI layer. A strength of ssh is how well it suits you when you want to dive on to a host and make a fast change.

Re: Looking Forward: Support for Secure Shell

#218

Post by XorNot »

hammerandtongs wrote: post #50
e40 wrote: post #42

Earlier quoted context omitted.

You're just trading sshd bugs for VPN bugs, in that case. Which are more likely? From what I know, I think I'll put my lot in with sshd. Perhaps I'm not well informed, though. Also, sshd + fwknop (port knocking) is a very secure combo, IMO.

With openvpn (which is just ssl) you can simply not respond when someone presents a bad key. openssh always responds (unless I've missed a recent feature) thus exposing which port its listening on and that you sent a bad key. The silent failure is preferable for this application. Port knocking gives you a roughly equivalent layer.

And both these things you never do in production because it takes little effort to establish there must be a port open, whereas the cumulative time you'll spend tracking down whether its a network issue or bad/wrong keys is just not worth it.

Not to mention: nobody's going to be brute-forcing properly generated keys remotely. And if they're not properly generated, you have much bigger problems.

Re: Looking Forward: Support for Secure Shell

#219

Post by baldfat »

eropple wrote: post #211
baldfat wrote: post #77

Earlier quoted context omitted.

Even better don't use default ports. Or have a second ssh that doesn't except any IP address at port 22 and than have your non-standard port with keys and limited user names and if possible a white list of your IP addresses.

Not using default ports will mildly confuse automated scans and do absolutely nothing to a determined attacker. Or somebody with nmap, which is not the same thing. If you're whitelisting IPs, you may as well run it on port 22.

No it makes it harder and more of a pain. Trust me I have a friend who loves breaking into my personal server. That one trick two ssh running on different ports screwed with him for a long, long time. He is a genius of a hacker and has been doing it for a living for years. When he finally got in he was so pissed that threw him.

Re: Looking Forward: Support for Secure Shell

#220

Post by pjc50 »

wvenable wrote: post #30
Someone1234 wrote: post #18

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

conhost is getting some upgrades in Windows 10: http://www.hanselman.com/blog/Windows10GetsAFreshCommandProm... Given that a lot of new development in the Windows world is focused on the console, I expect that we will see more enhancements in the future.

One thing that I'm not 100% clear on: have they fixed multi-line selection in the Win10 command prompt?
Post reply on HN