4 ms·

I don't see anyone sensible replacing OpenSSH with anything else for two fundamental reasons: 1. OpenSSH has more eyes on it and more deployments than almost a

I don't see anyone sensible replacing OpenSSH with anything else for two fundamental reasons: 1. OpenSSH has more eyes on it and more deployments than almost any other piece of non-OS/kernel software on the planet. By this stage in its life, it is very mature. Look at the vulnerability database, OpenSSH has not had a serious REMOTE vulnerability for a long time, all the recent vulnerabilities require the attacker to have some form of pre-existing host access (https://www.openssh.com/security.html https://www.openssh.com/security.html). 2. OpenSSH comes from the house of OpenBSD. Those guys are serious about writing secure code and have a well-established track record. These days you can also compile OpenSSH against LibreSSL instead of OpenSSL. Instead of replacing OpenSSH, most people would be better off spending their time switching OpenSSH to key-based-auth only and then making a few simple configuration changes to further harden OpenSSH. Starting with the config ideas proposed by Mozilla[1] and adding in options such as the built-in rate-limiting config options (PerSourceMaxStartups, PerSourceNetBlockSize and friends). [1] https://infosec.mozilla.org/guidelines/openssh https://infosec.mozilla.org/guidelines/openssh

wibblewobble125 3y ago
Bad reasons to trust code: * “Many __informal__ eyes have probably looked at it” * Lack of recent __number__ of (known) vulnerabilities * “Serious guys” (appeal to authority) I think you’re using short-hand, but perhaps the short-hand should be different. E.g. * A list of audits by date, independent organization, is provided __here__ which is evidence of review * The vulnerability acknowledgement, correction and release process is prompt, accurate and detailed, which is documented __here__ * XYZ coding, testing, fuzzing, proving, bounty, integration with other systems, documentation, defaults etc. practices are used in the interest in hardening the code, limiting moving parts, attack radius, etc.
- traceroute66 3y ago
  > I think you’re using short-hand Yes I was using short-hand. Because you're the only one here trying to make the stupid argument that OpenSSH code is somehow not trustworthy. Frankly, if you don't trust OpenSSH code for the reasons you suggest, then you should not be trusting any Operating System, whether BSD, Linux, Mac or Windows. As I said, OpenSSH is used extensively, INCLUDING in security-critical environments, the sort of security-critical environments that you can be sure have done their homework, even if they don't publish it. The simple fact of the matter is this: Given the widespread global deployment of OpenSSH for DECADES now, if there were shortcomings in the code, you would have heard of it because we would be seeing BILLIONS of compromised endpoints. Fact is, there aren't, unless you haven't bothered to update your system in the last decade. So you can talk about fuzzing or whatever until you are blue in the face, but widespread global deployment is hard to beat, because that's REAL WORLD, failed attempts at finding zero-day exploits and all !

wibblewobble125 3y ago

Bad reasons to trust code: * “Many __informal__ eyes have probably looked at it” * Lack of recent __number__ of (known) vulnerabilities * “Serious guys” (appeal to authority) I think you’re using short-hand, but perhaps the short-hand should be different. E.g. * A list of audits by date, independent organization, is provided __here__ which is evidence of review * The vulnerability acknowledgement, correction and release process is prompt, accurate and detailed, which is documented __here__ * XYZ coding, testing, fuzzing, proving, bounty, integration with other systems, documentation, defaults etc. practices are used in the interest in hardening the code, limiting moving parts, attack radius, etc.

traceroute66 3y ago
> I think you’re using short-hand Yes I was using short-hand. Because you're the only one here trying to make the stupid argument that OpenSSH code is somehow not trustworthy. Frankly, if you don't trust OpenSSH code for the reasons you suggest, then you should not be trusting any Operating System, whether BSD, Linux, Mac or Windows. As I said, OpenSSH is used extensively, INCLUDING in security-critical environments, the sort of security-critical environments that you can be sure have done their homework, even if they don't publish it. The simple fact of the matter is this: Given the widespread global deployment of OpenSSH for DECADES now, if there were shortcomings in the code, you would have heard of it because we would be seeing BILLIONS of compromised endpoints. Fact is, there aren't, unless you haven't bothered to update your system in the last decade. So you can talk about fuzzing or whatever until you are blue in the face, but widespread global deployment is hard to beat, because that's REAL WORLD, failed attempts at finding zero-day exploits and all !