'Detect Host Keys' does not clear previous result if the Repository URL has been updated to one that fails

Summary

When setting up a SSH repository push mirror, if the mirror repository URL is updated from one that works and Detect host keys button is pressed, the SSH Host fingerprints is displayed.

However, if the URL then gets changed to one that does not allow a successful connection from GitLab (because traffic is being blocked/dropped to the new host), the SSH fingerprint from the previous host is still displayed.

Related: #331869 (closed)

Steps to reproduce

  • Setup a instance that rejects 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 REJECT
iptables -I INPUT -s 34.74.226.0/24 -j REJECT
  • 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
  • Add a Git Repository URL of ssh://gitlab.com.
  • Click the Detect host keys button. SSH fingerprints should be displayed
  • Change the Git Repository URL to the instance created in the first step. For example, ssh://<instance_domainname_or_ip>.
  • Click the Detect host keys button
  • Observe that you receive a banner containing Failed to detect SSH host keys and the previous SSH fingerprints are still displayed.

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?

SSH fingerprints of previous host is still displayed.

What is the expected correct behavior?

SSH fingerprints of previous host should no longer be displayed, as it can cause confusion.

Output of checks

This bug happens on GitLab.com

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

Edited by Kenneth Chu