Use SHA256 fingerprint to authenticate SSH sessions

Problem to solve

When users authenticate over SSH with Fast SSH lookups enabled, gitlab-shell sends the entire base64-encoded SSH public key to the /api/internal/authorized_keys endpoint of GitLab. From there, we generate an MD5 fingerprint and use it to look up an SSH key that it matches.

Intended users

Further details

MD5 collisions are not too expensive to generate, so this is something of a security risk. It's likely to fail us in FIPS audits too, since MD5 is banned in that context.

In !19860 (merged) we started generating SHA256 fingerprints for keys. In !21579 (merged) we introduced a background migration that sets a SHA256 fingerprint for all keys. This means that we could start looking up by SHA256 fingerprint instead.

Proposal

Since gitlab-shell sends us the whole public key, not just the fingerprint, gitlab already has all the information it needs to calculate the sha256 fingerprint of that key and do a lookup based on that information, rather than on the MD5 fingerprint. We'd just need to make the change here: https://gitlab.com/gitlab-org/gitlab/blob/master/lib/api/internal/base.rb#L131

I've set this to security and made it confidential from an abundance of caution. I don't think we should treat this as a security issue, but @gitlab-com/gl-security/appsec might disagree. I'll set to non-confidential and remove the security label if I've not heard anything by the end of the week.

Testing

We should ensure that SSH operations still work with this change, since it involves end-to-end changes from SSH daemon right through to gitlab, via gitlab-shell.