I added an SSH key to my account on gitlab.com and was unable to use it to checkout my projects. Running
ssh -v firstname.lastname@example.org gave the following message:
$ ssh -v email@example.com OpenSSH_7.1p1-hpn14v5, OpenSSL 1.0.2d 9 Jul 2015 ... debug1: Connecting to gitlab.com [126.96.36.199] port 22. debug1: Connection established. ... debug1: Authentications that can continue: publickey debug1: Next authentication method: publickey debug1: Skipping ssh-dss key /home/chris/.ssh/id_dsa for not in PubkeyAcceptedKeyTypes debug1: No more authentication methods to try. Permission denied (publickey).
After adding an RSA key, I was able to clone my repositories as normal.
If the site does not accept SSH key authentication with DSA keys for whatever reason, it would be helpful if the page for adding SSH keys tells the user about this (e.g. a message saying "this server does not support authentication with DSA keys, please use an RSA or ECDSA key").
Yeah, I don't think GitLab can detect whether DSA is enabled since that would require reading the sshd config. I would think that it would suffice to recommend using RSA keys and print a warning message that DSA keys are deprecated and may not work with GitLab.
The key format is listed in the public key when it's added. RSA keys start with
ssh-rsaand dsa keys start with
ssh-dss. The user could be warned when adding the key that it might not be supported.
@foozmeat yes we could parse that bit of text and show a warning. But I am still not sure what the warning should be, or in what direction should be pushing the user. Imagine how annoying it would be to run GitLab on a server that rejects RSA client public keys, with GitLab telling every user to upload an RSA key.
I just came across this bug, and my instinct was to configure GitLab to reject ssh-dss keys, but I see there's probably no feature that allows this at present.
That's one solution, but requires manual intervention to recognise the problem. A warning is also potentially useful. However, one can probably probe the SSH server for the most robust option:
- Generate a set of keys to be used for probing, of all types.
- In turn, try to connect to git@servername in verbose mode, e.g.
ssh -vi mykey git@servername
- Look for
debug1: Skipping ssh-dss key mykey - not in PubkeyAcceptedKeyTypesand if found prevent that key type from being added, and mark that all existing keys of that type should have a warning beside them.
The problem is that this requires running an SSH client (server will have one, of course), and the question is how often this should be done. Maybe at every
gitlab-ctl reconfigure, for example.
Hey! It's been at least 2 weeks (and several releases of GitLab) since we heard from you. I'm closing this issue but if you still experience this problem, please open a new issue (but also reference the old issue(s)). Make sure to also include the necessary debugging information conforming to the issue tracker guidelines found in our contributing guidelines.
Thanks for using GitLab!
Status changed to closedToggle commit list