when setting up a pull mirror, the SSH key generated by gitlab is RSA, not ed255
Make gitlab generate ed255 ssh keys NOT deprecated insecure RSA keys which the latest openssh wont allow
It requires the user to add
PubkeyAcceptedKeyTypes=+ssh-rsa
HostKeyAlgorithms=+ssh-rsa
to the .ssh/config file of the repo host
[ 17.2.1-ee] Self-managed
Thanks for taking the time to be thorough in your request, it really helps! 
That statement is not quite correct. Some RSA keys are deprecated/insecure, but not all of them. For example a RHEL system with FIPS enabled won’t allow you to use ED25519 ssh keys, whereas SSH RSA 4096 are possible and are most definitely not deprecated. You are probably referring to RSA with shorter lengths like 1024.
Also, as far as I can see, Gitlab doesn’t generate SSH keys - I don’t see any functionality in the Gitlab GUI that does that. It does allow you to copy/paste keys that have been generated elsewhere. Therefore perhaps you are generating keys incorrectly from the SSH command line? Gitlab uses SSH what is already installed on the server.
Either way, posting what you did here will not get resolved, you would need to open an issue here: Issues · GitLab.org / GitLab · GitLab and you would also have to explain in a lot more detail in how you are generating the SSH key because I don’t believe this to be a Gitlab problem. ED25519 keys can be used with Gitlab, I use them. But I generated them using ssh-keygen which comes from openssh packages belonging to the Linux distribution.
The documentation for Gitlab is also clear how keys are generated and it’s easy to see ED25519 is supported: Use SSH keys to communicate with GitLab | GitLab
Hi ian,
And thanks for taking the time to reply. gitlab definitely DOES gen keys. Try to set up pull mirroring on one of your existing gitlab repo (in your chosen project, go to setting-repository: expand Mirroring Repositories), if you use SSH keys rather that account/password, then, to my surprise, gitlab generates a rsa public key for mirroring JUST this repo mirror activity. It does NOT allow you to provide the key.
It’s an interesting design choice by gitlab - I would just get the user to upload a private key to use. Saves a lot of hassle, especially if the user has to set up mirroring for 27 repos.
In the end I’ve gone ditched the idea of mirroring using SSH keys - this gitlab solution doesn’t work for me. I’ll raise it with gitlab next time I have them on a call.
Yep just seen that, so you’ll need to open an issue with Gitlab perhaps requesting that they add the ability to provide your own rather than force controlling what key should be used.
I don’t have this problem because I mirror over https, and use access tokens for this. I don’t tend to use ssh, and in fact I’ve restricted access to our servers via SSH to administrative tasks only and force all users to use https.