Unsupported type of credentials provided, either SSH private key or username/password is supported (exit code 110)

[SihengCui]

For private HTTP git repositories, the name references a secret in the namespace that contains username and password.

kind: Build
metadata:
  name: builder-zps9k-build-ktbvv
  namespace: default
  labels:
    openfunction.io/builder: builder-zps9k
  resourceVersion: '3629355'
spec:
  builder:
    image: openfunction/builder-go:latest
  output:
    credentials:
      name: push-secret
    image: "xxx"
  paramValues:
    - name: ENV_VARS
      value: FUNC_CLEAR_SOURCE=true#FUNC_GOPROXY=https://goproxy.cn#FUNC_NAME=HelloWorld#PORT=8080
  source:
    credentials:
      name: basic-user-pass
    revision: master
    url: http://bitbucket.xxx/xxx/serverless-example.git
  strategy:
    kind: ClusterBuildStrategy
    name: openfunction

kind: Secret
apiVersion: v1
metadata:
  name: basic-user-pass
  namespace: default
  annotations:
    tekton.dev/git-0: http://bitbucket.xxx
  resourceVersion: '3421673'
data:
  password: xxxx
  username: xxxx
type: kubernetes.io/basic-auth

Looking at the Pod, it is found that the container that pulls the code exist the following command /ko-app/git ... --secret-path /workspace/shp-source-secret I keep the container, cd to the /workspace/shp-source-secret and find that there are two files username and password, when I manually execute /ko-app/git ... --secret-path /workspace/shp-source-secret ， it also printUnsupported type of credentials provided, either SSH private key or username/password is supported (exit code 110).

Why, is my certificate format wrong?

[dheerajodha]

I could be wrong but maybe this might help: https://github.com/shipwright-io/build/issues/968#issuecomment-1008932577

[SaschaSchwarze0]

@SihengCui when you created the secret, where xxxx plain text or base64 encoded ? It should be the latter, or you use stringData to provide plain-text and the Kubernetes will encode it. Above mentioned PR improves our documentation as passwords are not supported anymore, but instead it must be a token.

[SihengCui]

@SihengCui when you created the secret, where xxxx plain text or base64 encoded ? It should be the latter, or you use stringData to provide plain-text and the Kubernetes will encode it. Above mentioned PR improves our documentation as passwords are not supported anymore, but instead it must be a token.

emmm.. Do you mean that the password field is filled with the token string? But the git repo is a private Bitbucket. It seems that there is only password. In this case, is there any way to pass the certification?

[SaschaSchwarze0]

I have never used BitBucket, but seems like will need some (doc?) changes based on https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/#Cloning-a-repository-with-an-access-token. @SihengCui can you try what happens when you put x-token-auth as username into the secret and your access token as password?

[SihengCui]

I have never used BitBucket, but seems like will need some (doc?) changes based on https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/#Cloning-a-repository-with-an-access-token. @SihengCui can you try what happens when you put x-token-auth as username into the secret and your access token as password?

There are something different with git repo using HTTP or HTTPS protocol. I chose a non-existing domain as my repo address git.sihengcui.com.

url: http://git.sihengcui.com/scm/serverless-example.git

2022/10/10 08:46:24 Info: ssh (/usr/bin/ssh): OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021
2022/10/10 08:46:24 Info: git (/usr/bin/git): git version 2.31.1
2022/10/10 08:46:24 Info: git-lfs (/usr/bin/git-lfs): git-lfs/2.13.3 (GitHub; linux amd64; go 1.17.5)
2022/10/10 08:46:24 /usr/bin/git clone -h
2022/10/10 08:46:24 /usr/bin/git submodule -h
2022/10/10 08:46:24 Unsupported type of credentials provided, either SSH private key or username/password is supported (exit code 110)

After that I just modified http to https. url: https://git.sihengcui.com/scm/serverless-example.git It did not prompt "Unsupported type".

2022/10/10 08:51:10 Info: ssh (/usr/bin/ssh): OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021
2022/10/10 08:51:10 Info: git (/usr/bin/git): git version 2.31.1
2022/10/10 08:51:10 Info: git-lfs (/usr/bin/git-lfs): git-lfs/2.13.3 (GitHub; linux amd64; go 1.17.5)
2022/10/10 08:51:10 /usr/bin/git clone -h
2022/10/10 08:51:10 /usr/bin/git submodule -h
2022/10/10 08:51:10 /usr/bin/git clone --quiet --no-tags --single-branch --branch master --depth 1 -c credential.helper=store --file /tmp/cred-helper-file3502023043 -- https://git.sihengcui.com/scm/serverless-example.git /workspace/source
2022/10/10 08:51:11 fatal: unable to access 'https://git.sihengcui.com/scm/serverless-example.git/': Could not resolve host: git.sihengcui.com (exit code 128)

Could this be the cause ?

[SihengCui]

I have never used BitBucket, but seems like will need some (doc?) changes based on https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/#Cloning-a-repository-with-an-access-token. @SihengCui can you try what happens when you put x-token-auth as username into the secret and your access token as password?

I put access token as password. And success pull the private repository from my github. So I am sure the format of the secret is correct. When the url is replaced with http://bitbucket.xxxxx, even if the username and token are not replaced, a 401 authentication error should be returned instead of Unsupported type.

[SaschaSchwarze0]

From grooming:

• We do not want to send username/password credentials using a cleartext protocol like HTTP. We should improve the error message, though. -> #1131
• We need to verify https://support.atlassian.com/bitbucket-cloud/docs/use-oauth-on-bitbucket-cloud/#Cloning-a-repository-with-an-access-token. Today, when somebody clones using HTTPS with username/password, then we use Git's credential helper. But we don't know how this maps to the Git clone command. To be checked, fixed if necessary, and updated in the docs if appropriate. -> #1132
• We should also check if somebody really does what BitBucket does = putting credentials into the .spec.source.url field of the Build. This will maybe work, but we will also likely leak the password in the logs of the source-default step. Though, it should generally not be recommended to do this at all because the password is then unencrypted in etcd. Maybe also worth a hint in the docs. -> #1133

[dheerajodha]

Hi @SihengCui, if possible, can you help me by providing the exact yaml files you used as a step to reproduce this problem? I want to try fixing this but I notice you've added a few 'xxx' in parts of the yaml file above and I'm not sure which values to add there.

[SihengCui]

Hi @SihengCui, if possible, can you help me by providing the exact yaml files you used as a step to reproduce this problem? I want to try fixing this but I notice you've added a few 'xxx' in parts of the yaml file above and I'm not sure which values to add there.

That's a private git address on an internal network. If you need to reproduce the problem, just request any of the HTTP repositories. NOT https

[dheerajodha]

That's a private git address on an internal network. If you need to reproduce the problem, just request any of the HTTP repositories. NOT https

Awesome, I'll do that. Thank you!