When Adding SSH Public and Private keys via the GIT Repo Config page, SSH key ends up as null.

[rfutterman91]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current Behavior

I am trying to connect my AWS Code Commit repo to Rancher Fleet GIT Repos. I enter in my public and private keys in OPENSSH format. Once I save and look back at the config it shows SSH Key: Null

This is the Error I see on the Git Repo dashboard:

Git ls-remote ssh://git-codecommit.us-gov-west-1.amazonaws.com/v1/repos/linc-noss-fleet refs/heads/main error: exit status 128, detail: gitjob@git-codecommit.us-gov-west-1.amazonaws.com: Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.

the repository exists as I am copying it from AWS CodeCommit

Expected Behavior

SSH Keys to be generated properly

Steps To Reproduce

1. Continuous Delivery > Git repo > Add Repository
2. Use SSH keys generated from AWS Code Commit in OpenSSH format
3. Save
4. Look at the config for the repo and notice 'SSH Key: null'

Environment

- Architecture:
- Fleet Version:
- Cluster:
  - Provider:
  - Options:
  - Kubernetes Version:

Logs

No response

Anything else?

No response

[manno]

Does it work when you create the secret, which contains the keys, with kubectl instead of the Rancher UI? https://fleet.rancher.io/next/gitrepo-add#adding-private-git-repository

This sounds like a UI bug.

[Tejeev]

If any Hosted Rancher users are running into this, you can create a new CD pipeline by cloning a working one. Otherwise, please speak to your hosted support engineer.

(anyone can create a new pipeline by cloning, but you can't manage the upstream Rancher cluster in Hosted instances so the kubectl manual workaround isn't an option)

[RP-TSB]

hey @rfutterman91 , I faced this issue last week, the way I found to solved those issues was:

• To add a space and then a relevant name at the end of the public key, this will be the name displayed where you see Null now
• To add an empty line at the end of the public and private keys, this will make the GitJob to finish successfully, it otherwise says invalid format on the logs.

I know it's not a solution but at least you could keep working on your real goal.

[thyarles]

On my tests I saw that the SSH secret is being created on the namespace cattle-fleet-system instead of the fleet-default one. To solve it I created the SSH secret upfront on the right namespace and next I just linked it on the GitRepo setup.

[kkaempf]

closing as of last comments

[Tejeev]

It looks like the fix for this should be in 2.6.11 Please let us know if it does not work as expected

[RP-TSB]

hey @kkaempf , please don't close it and reconsider the tag bug since it actually is. The parser on the UI is not alerting the user of these caveats and manual steps one has to make in order to get it working correctly. One shouldn't go to K8s namespaces and modify/create resources manually wherever Rancher provides an interface for it.

[manno]

I created keys with ssh-keygen -ftest. In my tests on 2.7-head the keys were created correctly in secrets. The secrets were in the right namespace and contained the keys as entered in the UI.

However, the UI tries to show a name for each key. If the public key is missing a "name" or does not fit OpenSSH's own format (ssh-rsa Alongb64str= test@test.localhost) the name field in will be "null". This can happen if users enter the key, not in OpenSSH own format, but in a different one, like , the RFC4716 format.

Advice from fleet docs might not be accurate anymore:

• If you are using openssh format for the private key and you are creating it in the UI, make sure a carriage return is appended in the end of the private key.
• The key has to be in PEM format.
• Note: The private key format has to be in EC PRIVATE KEY, RSA PRIVATE KEY or PRIVATE KEY and should not contain a passphase.

Key requirements should become clearer as we progress on https://github.com/rancher/fleet/issues/1504.

[Tejeev]

One of the users I support has reported they do not see the issue they reported (we believe it to be this one) as of 2.7.3 This may not be true for everyone, so please test and let us know what you are seeing. I believe the UI and docs updates are still in the works.

[sbulage]

I am able to see the secrets created via GitRepo UI page, already created secrets (http/ssh) both are populated. Also, used them in order to deploy applications from private GitHub repository.

[thyarles]

I'll give it a try. Thanks.