'Detect Host Keys' fails silently if a SSH push mirror drops traffic from gitlab.com

Summary

When setting up a SSH repository push mirror, if the repository is dropping traffic from gitlab.com, and so gitlab.com fails to connect from a timeout, the Detect host keys button remains greyed out with no indication of a failure.

Steps to reproduce

• Setup a instance that drops SSH (port 22) traffic from GitLab.com's IP range. This instance does not need to be running gitlab, only SSH. For example:

iptables -I INPUT -s 34.74.90.64/28 -j DROP
iptables -I INPUT -s 34.74.226.0/24 -j DROP

• Go to any project on gitlab.com that you have maintainer or owner permissions on.
• Go to add a SSH repository mirror under Settings -> Repository
• Setup a push mirror
• For the Git Repository URL use ssh://<instance_domainname_or_ip>.
• Click the Detect host keys button
• Observe that the Detect host keys button remains greyed out with no indication of a failure

Note: it seems that gitlab.com caches the response from the endpoint, so you may need to use another instance/domain/IP or wait for the result to be removed from the cache (seems to be at least longer than 10 minutes in my test) if you decide to play around with Dropping/Rejecting/Allowing SSH traffic from the self-managed instance.

Example Project

Customer project in this internal ticket: https://gitlab.zendesk.com/agent/tickets/212464

What is the current bug behavior?

Detect Host Keys shows no signs of failure

What is the expected correct behavior?

Detect Host Keys should show signs of failure

Relevant logs and/or screenshots

Output of checks

This bug happens on GitLab.com

https://gitlab.com/help: GitLab Enterprise Edition 13.13.0-pre 19d68686