SSH auth not valid to git repo when port set in path

[CamrynCarter]

Is there an existing issue for this?

• [x] I have searched the existing issues

Current Behavior

When attempting to add a new git repo to fleet using ssh auth, specifying a port in the url field causes a 'no known hosts' error. The UI validation now prevents setting a port as part of the path and it must be done via yaml editor. This used to be possible without error.

Expected Behavior

Auth should be allowed to repo URL even with port specified. UI validation shouldn't prevent specification of port

Steps To Reproduce

1. Add new git repo
2. Specify repo url including port, UI validation blocks, so set via yaml
3. Add ssh keys
4. Choose create, no known hosts error.

Environment

- Architecture:
- Fleet Version: fleet-107.0.4+up0.13.4
- Cluster:
  - Provider:
  - Options:
  - Kubernetes Version:

Logs

Anything else?

Could add a check box to optionally ignore known hosts (or fix port issue)

Ideally remove UI validation that prevents specifying port in path

[CamrynCarter]

[email protected]:path/fleet.git is valid but [email protected]:2222/path/fleet.git is not valid

[nikos445]

Same here.

[sbulage]

• Tested with latest 2.13-head and Fleet: 0.14.0-beta

  It worked for me, without any error, as I have added known_hosts from the output of ssh-keyscan -p 2222 <IP>, See below screenshot.

  

• Tested with Rancher 2.12.3 and Fleet: 0.13.4

  • I can confirm that there is UI validation which don't allow me to click on Next button.
  • I can see that known_hosts error after editing via YAML.

    Failed to clone repo from branch repo="ssh://[email protected]:2222/home/git/repos/test-new.git" branch="master" revision="" path="/workspace": ssh: handshake failed: knownhosts: key is unknown:ssh: handshake failed: knownhosts: key is unknown
    

I hope that helps.

[sbulage]

Followed this document to get the knowns_hosts --> https://fleet.rancher.io/0.13/gitrepo-add#known-hosts

[EdKingscote]

We are also using port 2222 for our git SSH connectivity. Our short-term workaround is to return to having fleet configured with 'insecureSkipHostKeyChecks: true'

A question that has arisen in my mind (because I don't recall manually setting this before) is whether upgrades have been carrying forward the setting to bypass the check and only fresh installations are being impacted right now, or whether I did do this previously and just don't remember doing it.