Problem to solve
It adds support for the server-sig-algs extension on server side. The supported algorithms are sent via SSH_MSG_EXT_INFO message. It's inspired by https://github.com/golang/crypto/pull/197/files, but takes only the part that allows a server to send
server-sig-algs to a client; client-side and ability to provide custom extensions are omitted.
Now SSH2_MSG_EXT_INFO with specified list of algorithms is sent:
debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
Fixes: gitlab-shell#543 (closed)
Q & A
If a server does not send this extension, a client MUST NOT make any assumptions about the server's public key algorithm support, and MAY proceed with authentication requests using trial and error. Note that implementations are known to exist that apply authentication penalties if the client attempts to use an unexpected public key algorithm.
Is this exposing a client bug/shortcoming related to disabling SHA-1?
- Before 8.8 version, OpenSSH client tried and sent
ssh-rsapublic keys, even if a server didn't send the extension. But since 8.8, OpenSSH client doesn't do it by default. It requires either a client to specify
-o PubkeyAcceptedAlgorithms=ssh-rsaoption to preserve the previous behavior or a server to send the extension
- If there is some CVE in this package before this upstream changes are merged, we're going to have to maintain this fork and possibly deal with conflicts. Are we okay with that?
- Yes, but it doesn't seem to be a huge overhead (in case we don't have complex conflicts). Gitlab Shell maintainers will be responsible for doing it.
- Since https://github.com/golang/crypto/pull/197/files and https://go-review.googlesource.com/c/crypto/+/360195#message-899ce2286fdf8997922b71d87f86b47e62108822 seem to have be open since November without further comments/activity, is there anything we can do to help speed up this?
- According to https://github.com/golang/crypto/pull/197#issuecomment-978132412 this PR is discussed in Slack directly with the maintainers. Since the PR suggests changes to API (ability to customize the extensions), I understand why it may take some time. The plan is to focus on our own problem and move forward with gitlab-sshd deployment. Then we could share our findings or suggest merging a smaller iteration.
The fork is temporary
We're forking the package just to move forward with gitlab-sshd deployment. When the upstream code in ssh: add support for extension negotiation (rfc 8308) is merged, we can remove the fork and use the upstream instead.