Skip to content

SSH signing keys should not be accepted by sshd

Summary

Amazing that GitLab supports commit signing with SSH keys! 🎉

But I did run into something unexpected: My signing key gets accepted by your sshd server as an "authorized key" to access / authenticate to GitLab, even though I specifically restricted it to be for signing only.

Now, this is not a security issue, because after a successful connection the request still fails with the following message:

remote: 
remote: ========================================================================
remote: 
remote: The project you were looking for could not be found or you don't have permission to view it.
remote: 
remote: ========================================================================
remote:

But what's problematic about it is that it doesn't play well with existing SSH clients and integrations on the market, because they all follow the normal SSH protocols (as they should), and therefore assume that if sshd accepts a key, access is in fact granted. But in reality, after GitLab's sshd layer tells the SSH clients that it accepts the signing key for authentication, the SSH request still fails after the fact.

And because the incorrect key got accepted by GitLab, SSH clients stop trying out other keys for authentication.

Steps to reproduce

  1. Add an SSH signing key and an SSH authentication key to GitLab.
  2. Add them to your local SSH agent:
ssh-add /path/to/signing-key
ssh-add /path/to/authentication-key
  1. Run a Git command that does an SSH request to GitLab: git fetch.
  2. GitLab's sshd tells my client that it accepts the key, but then still aborts the request afterwards.

Workaround

Because the order that the keys are present in an SSH agent determines the order they're tried in an SSH request, one way to work around this issue is to add the keys in a different order, adding the authentication key first. However, some SSH agent solutions and SSH tools (like the 1Password SSH agent) don't give users control to change the key order.

A second workaround is to use -i or IdentityFile with the authentication (public) key. However, not every SSH and Git client out there supports this.

What is the current bug behavior?

sshd accepts a signing key, which it shouldn't.

What is the expected correct behavior?

sshd only accepting an authentication key, just like GitHub does it.

Edited by floris