Hi OpenSSH developers; Thank you for your amazing work. I’m emailing to see if any knowledgeable OpenSSH developer is willing to help us review / revamp some patches we have for OpenSSH, and provide advice on some of the more advanced uses of OpenSSH. This would be a for pay contract engagement. We are trying to be super respectful of the process, and are happy to be very creative – we are willing to open source our patches, pay directly, donate to openssh/openbsd, donate hardware if applicable, etc., as desired by a developer. Having contributed to open source before, but never having tried to request contract work before, we’re trying to be very flexible. We are looking for a review of our current patches, especially with an eye to security and completeness. Our current patches introduce: - A similar feature to permitopen in the authorized_keys file, except for gateway ports. Whereas permitopen defines what an ssh -L can do, our permitgwopen option does similar for what a ssh -R client could request. - Defaults sshd to not open ports, unless explicitely permitted by a permitopen or permitgwopen statement. - Except as permitted otherwise, no data should be forwardable one way or another. - Basically, make a ssh client unable to open anything except that which is explicitly defined at the server using authorized_keys methods. Additionally, we’re looking for some creative advice around handling thousands of keys in our specific environment. As I said, we’re more than happy to open source our patches or development (or not) – I’m sensitive to the fact that patches we develop may never become part of OpenSSH mainline, and we’re fine with that. Or if they do become part of OpenSSH mainline, we’re fine to sign off on that too. We haven’t done so far because we really aren’t looking to manage a public debate - we needed to solve a problem, and have a working solution and want to readdress. I want to thank the key openssh contributers I’ve reached out to so far for their consideration about this request – thank you for your time and attention. Prospective interested parties should contact me via email, or if desired by public posting in response to my email. Thanks, Devin Nate --- Director of Technology, QHR Technologies Inc. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
