2021. What an interesting year. With the world turned upside down by a pandemic that seemingly had its sights set on...
Why You Also Need OpenSSH
Randall S. Becker, Nexbridge Inc., Chief Architect NSGit, Porting Hero at ITUGLIB, Platform Maintainer for Git, OpenSSL, OpenSSH.
It has been two years since I said anything publicly about OpenSSH, but things have moved since 2020. I’ve learned a lot about the subtleties of how OpenSSH self-configures – it is a lot different than Git and OpenSSL, so there’s not a lot of portable knowledge there; but that is already enough about me. What is going on with OpenSSH?
The previous version of OpenSSH, 7.6p1 goes back a few years. I used to take the ported changes from prior versions and apply them using git merge then dealt with conflicts and other changes. It worked pretty well until some new functionality came in that broke the merge. In those days, the official ITUGLIB port used FLOSS to make the code work. By 8.0, the code had diverged so much that the merges were useless. This happens as a normal thing sometimes as code evolves. The old adage that software decays over time definitely applies to merges. However, through all that, 7.6p1 was functional, and more importantly was needed when NonStop SSH was not available to everyone. Now that it is, why bother with OpenSSH?
Well, that is a very good question, Randall: why did you bother even trying to port 8.8p1 at this time?
The Reasons for the 8.8 Port
Reason #1: In all cases with anything SSH and SSL is compatibility of certificate cyphers. Older versions just do not have the up-to-date cyphers that are compatible with L21.06 NonStop SSH, GitHub, BitBucket, etc. As hackers do their worst, cyphers are broken and must be replaced. Technology, like quantum computing is expected to do even more damage and make us at least double our key sizes. So, 7.6p1 was just out of date with regards to what kind of cryptography could be used. Justification enough. Full stop.
Reason #2: Not everyone has ssh-keygen on their workstations or cannot upload keys to their NonStop. Having a functional way to generate complex keys directly on NonStop has value. This is partly related to Reason #1.
Reason #3: This is my biggest reason, and possibly yours: As of late 2021, git added support for SSH key signing. This a really big deal because GnuPG has a similar issue to the older OpenSSH – not enough cryptographic functions. So now, you can sign your work, your commits, your tags, with SSH keys that are published on your private or public GitHub. From an audit standpoint, this is huge because you can get lists of public keys from GitHub and do your verification without having to build a GnuPG key management data store. This is not so much an OpenSSH thing, which supported content signing a few years ago at 8.0, but with capabilities added to git in response to it.
And of course, all this signing works in NSGit also – the only version control system that supports SSH key signing on NonStop, I might add.
Reason #4: The whole signing subject is pretty broad and there are some really cool features. One of the best, in my view, is the signing interval, which essentially acts like an SSL certificate when a start and end date. Speaking as a developer and repository manager, this capability completely justifies porting ad moving to the new release entirely based on The Rule of Cool – this is so cool that it is its own justification. FYI: this is the new OpenSSH ssh-keygen -V option
There are more reasons, and if reading the modern ssh-keygen man page does not have you desiring this, I’m not sure what else will pique your interest.
Status of the Port
As it stands now, I am working with the OpenSSH team to include my changes into the main code base. Unlike the previous port, this one does not use FLOSS to emulate unsupported functions. Both J06.22 and L20.10 are sufficient for the port, once you have zlibc from ITUGLIB. The port sets up basic c99 compiler options need for the build and deals with some of the weird mistakes that the configure infrastructure sadly makes on NonStop. This is basically a brand-new port and should not require me to merge changes if the OpenSSH team accepts the contribution.
Why You Need This New Port
I hope you enjoyed this briefing on OpenSSH. And now, I have to go do a stretch and fold on another batch of my world-famous COVID sourdough bread.
But before that, I tend to leave the hard questions for the conclusion, much to the chagrin of my grade 10 composition teacher: Do you really need to have OpenSSH?
Here is a bullet list:
- If you need to talk to servers that requires cyphers that NonStop SSH does not have, you need this version of OpenSSH.
- If you need to sign your work in git and/or NSGit, you need this version of OpenSSH.
- If your key pairs need to be time-limited, you need this version of OpenSSH.
- If you need to generate keys on your NonStop outside of NonStop SSH, you definitely need this version.
- If the available port of GnuPG makes you feel vulnerable, you also need this version of OpenSSH.