Live data from Hacker News

Looking Forward: Support for Secure Shell

blogs.msdn.com

41–50 of 404 posts

Re: Looking Forward: Support for Secure Shell

#41

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.

Fortunately that will change for Debian, and, we can hope, Debian-based distributions.

https://wiki.debian.org/ReproducibleBuilds

(I gave a talk about this at CCC. The status quo is a reason why free software doesn't have some of the transparency benefits over proprietary software we might expect, if you fear some developer is attacking you or someone is attacking some developers' infrastructure.)

Re: Looking Forward: Support for Secure Shell

#42
post #31

Earlier quoted context omitted.

>OpenSSH is exposed to the internet a lot (even if, yes, that is not best practice) Please elaborate.

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

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.

Re: Looking Forward: Support for Secure Shell

#43
post #24
post #19

> Given our changes in leadership and culture, we decided to give it another try and this time, because we are able to show the clear and compelling customer value, the company is very supportive. Is that code for Ballmer's regime vs Nadella's regime?

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-men who live in their own world shut off from what was happening in real world. He was douche all around from what I can tell and him leaving is one of the best things that could have happened to MS. Ballmer took over MS soon after I really got into computers and let it stagnate (XP/IE6) which lead me to switch to Linux/OSX and I've never looked back. I'm not saying it's all his fault but I think he was extremely influential in decisions that ultimately pushed me away from MS.

Re: Looking Forward: Support for Secure Shell

#44
post #41

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

Fortunately that will change for Debian, and, we can hope, Debian-based distributions. https://wiki.debian.org/ReproducibleBuilds (I gave a talk about this at CCC. The status quo is a reason why free software doesn't have some of the transparency benefits over proprietary software we might expect, if you fear some developer is attacking you or someone is attacking some developers' infrastructure.)

jeez, great post. sorry for my bad humour at you the other day. es tut mir leid.

Re: Looking Forward: Support for Secure Shell

#46
post #36

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

They might actually create a usable consumer OS given enough time to fix the garbage in Linux.

I think you're confusing linux (the kernel) with linux distributions (mostly lousy windows managers that run on linux).

Let's not get into an OS war between us here, but looking at the changes over the last 15 years, it's clear that MS is warming up to Linux. This is something that was absolutely unthinkable during the Gates and Ballmer eras.

The linux community must be doing something right when developer demand and excitement is so high for ssh.

Re: Looking Forward: Support for Secure Shell

#47
OH THANK GOD. I'm using Ansible to manage Windows, and today that means fooling around with WinRM. For example, that involved adding Kerberos support to Ansible so that it could authenticate against Windows domain accounts, because those are authed differently from local machine accounts.

Assuming the project succeeds this time around, it's going to be way easier to incorporate Windows servers into Unix-centric management systems. That's a huge benefit to DevOps and Microsoft. Thanks!

Re: Looking Forward: Support for Secure Shell

#48
post #42
post #31

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

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.

PubkeyAuthentication and disabling password logins helps a lot too. I've also been using deny_hosts a lot over the last couple years as an extra layer.

Re: Looking Forward: Support for Secure Shell

#50
post #42
post #31

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

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.

Post reply on HN