Docker’s credential-pass - no basic auth credentials

I set-up docker credential-pass using the references:

  1. https://blog.marcnuri.com/how-to-initialize-docker-credential-pass
  2. https://github.com/docker/docker-credential-helpers

I came across a GitHub Link also:
https://github.com/docker/docker-credential-helpers/issues/102


I installed the below release:

wget https://github.com/docker/docker-credential-helpers/releases/download/v0.9.3/docker-credential-pass-v0.9.3.linux-amd64   -O docker-credential-pass

I even configured

$ nano ~/.bashrc

Then added export GPG_TTY=$(tty)

$ source ~/.bashrc

Below are version details:

$ gpg --version
gpg (GnuPG) 2.4.4
libgcrypt 1.10.3
Copyright (C) 2024 g10 Code GmbH
$ docker --version
Docker version 28.1.1, build 4eba377
$ uname -m
x86_64
hostnamectl
Operating System: Ubuntu 24.04.1 LTS              
          Kernel: Linux 6.8.0-60-generic
    Architecture: x86-64
pass --version
v1.7.4

But when I do:

docker login
docker pull
docker logout

During the docker pull, I get the error no basic auth credentials. This behaviour is observed sometimes. After setting the credentials-helper, sometimes it works, but sometimes I get the error no basic auth credentials.
When I try to run the docker commands manually, it asks me for the passphrase. Once the passphrase is entered, and I try docker login, docker pull and docker logout, it works. But again after sometime, it gives the error.

Sometimes, after running two or three times the 3 above docker steps, when running the commands manually on the terminal, it asks for passphrase.

This behaviour is even observed when I try to run docker push.

**22:12:20** no basic auth credentials
script returned exit code 1

To note:
I was setting the credential helper on the Jenkins server in order to authenticate the Jenkins user for my pipelines on Jenkins. When I try to run multiple pipelines on Jenkins, sometimes I encounter the error
429 Too Many Requests - Server message: toomanyrequests: You have reached your unauthenticated pull rate limit.
That was the reason to authenticate and I performed the setup of credentials helper.

https://docs.docker.com/docker-hub/usage/pulls/


Also, there is another workaround, to do docker login for the jenkins user:

                  withCredentials([
                    [$class: 'UsernamePasswordMultiBinding', credentialsId: dockerHubCredentials, usernameVariable: 'DH_Username', passwordVariable: 'DH_Password']
                  ]) {
                    sh "echo '${DH_Password}' | docker login --username '${DH_Username}' --password-stdin"
                  }

Once you perform the docker pull for instance, I added the docker logout in the Jenkinsfile.
Note: In this method, Docker stores credentials in the config.json file in a base64-encoded format.
These credentials are removed when we do docker logout.

Is this some kind of bug with the credentials helper?


I have another query:

The auths section of the config.json has the private registry, for example, "privateregistry.abcd.cs.docker.fr": {} and the "https://index.docker.io/v1/" . I added "credsStore": "pass". Is it the case that when we try to run docker pull it preferred the https:// version of the credential, and attempt to pull the image with the empty credential, and so gave the error no basic auth credentials. If yes, how can we fix this problem?

Have you also experienced the issue when ran docker pull manually, or only when jenkins ran it after you manually ran docker login?

When you say “https version”, do you mean Docker hub? When you pull an image, you Docker uses the full docker image reference to recognize which registry the image is from. I don’t think it could try another registry.

I also don’t think I ever heard of using “pass” in a CI/CD pipeline. If you don’t like the credentials added to your general docker client config file, you can overide the docker config path temporarily.

So you could even use a file on tmpfs and remove the entire file after the build if Jenkins doesn’t do that. .

I encountered a similar issue today trying to configure credential-pass with a private registry :

I am using docker 28.3.2 with pass 1.7.4 and docker-credential-helpers 0.9.3 for Linux (pass)

I did the following :
login my.private.registry:5000 username
Which produce the following entry in ~/.docker/config.json

{
        "auths": {
                "my.private.registry:5000": {}
        },
        "credsStore": "pass"
}

And I can see the registered entry in credential-pass :

docker-credential-pass list
{"my.private.registry:5000":"username"}

And also in pass itself :

pass list
Password Store
└── docker-credential-helpers
    └── bXkucHJpdmF0ZS5yZWdpc3RyeTo1MDAwCg==
        └── username

But when I do a docker pull I have the no basic auth credentials error

docker pull my.private.registry:5000/hello-world
Using default tag: latest
Error response from daemon: Head "https://my.private.registry:5000/v2/hello-world/manifests/latest": no basic auth credentials

Have you tried it with Docker Hub? I wonder how similar your issue to the original in this topic. Yours could be something with private registries

Hello

The Jenkins pipeline gives a warning

**15:21:05** WARNING! Your credentials are stored unencrypted in '/home/user/.docker/config.json'.


**15:21:05** Configure a credential helper to remove this warning. See https://docs.docker.com/go/credential-store/

This was the reason I wanted to do the setup of credentials helper.

I experienced this issue even when running docker pull manually.

The “https version” in this context refers to the Docker registry URL:
**https://index.docker.io/v1/**

So one of my queries was:
Is it the case that docker gives priority to the https://index.docker.io/v1/ version?

Yes, the docker cli returns that general warning, but as far as I remember, it is also shown when using automated build on Docker Hub. I’m not sure, because I haven’t checked a recently. If Jenkins can handle the files better in any way, its own recommended solution should be used. Otherwise I think you can ignore the warning.

The URL of Docker Hub’s registry is not relevant when you are not using it. Docker will not care about a part of an URL, that contains a version number as it would be useless for another image from another registry.

Just to make sure we are talking about the same thing, you mean you ran docker login, logged in successfully, docker pull worked and later it didn’t and didn’t even ask for the gpg passphrase again? Did I understand it correctly?

When I do docker pull manually, the behavior is inconsistent. Sometimes, it gives no basic auth credentials, then when I re-run docker pull again, it asks for passphrase, then I do docker logout. Next time I re-run docker login, docker pull and logout it works without asking for passphrase. But again after sometime if I run these commands manually, it gives error and on doing docker pull again asks for passphrase.

Before we continue, let me share a question template. Just ignore the windows-related part

We usually need the following information to understand the issue:

  1. What platform are you using? Windows, Linux or macOS? Which version of the operating systems? In case of Linux, which distribution?

  2. How did you install Docker? Sharing the platform almost answers it, but only almost. Direct links to the followed guide can be useful.

  3. On debian based Linux, the following commands can give us some idea and recognize incorrectly installed Docker:

    docker info
    docker version
    

    Review the output before sharing and remove confidential data if any appears (public IP for example)

    dpkg -l 'docker*' | grep '^ii'
    snap list docker
    

    When you share the outputs, always format your posts according to the following guide: How to format your forum posts

~$ uname -m
x86_64
~$ uname -r
6.8.0-60-generic

~$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.1 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.1 LTS (Noble Numbat)"
~$ which docker
/usr/bin/docker

~$ docker version
Client: Docker Engine - Community
 Version:           28.1.1
 API version:       1.49
 Go version:        go1.23.8
 Git commit:        4eba377
 Built:             Fri Apr 18 09:52:14 2025
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          28.1.1
  API version:      1.49 (minimum version 1.24)
  Go version:       go1.23.8
  Git commit:       01f442b
  Built:            Fri Apr 18 09:52:14 2025
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.7.27
  GitCommit:        05044ec0a9a75232cad458027ca83437aae3f4da
 runc:
  Version:          1.2.5
  GitCommit:        v1.2.5-0-g59923ef
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0


~$ dpkg -l 'docker*' | grep '^ii'
ii  docker-buildx-plugin      0.23.0-1~ubuntu.24.04~noble   amd64        Docker Buildx cli plugin.
ii  docker-ce                 5:28.1.1-1~ubuntu.24.04~noble amd64        Docker: the open-source application container engine
ii  docker-ce-cli             5:28.1.1-1~ubuntu.24.04~noble amd64        Docker CLI: the open-source application container engine
ii  docker-ce-rootless-extras 5:28.1.1-1~ubuntu.24.04~noble amd64        Rootless support for Docker.
ii  docker-compose-plugin     2.35.1-1~ubuntu.24.04~noble   amd64        Docker Compose (V2) plugin for the Docker CLI.
ii  docker-scan-plugin        0.23.0~ubuntu-jammy           amd64        Docker scan cli plugin.
~$ docker info
Client: Docker Engine - Community
 Version:    28.1.1
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.23.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.35.1
    Path:     /usr/libexec/docker/cli-plugins/docker-compose
  scan: Docker Scan (Docker Inc.)
    Version:  v0.23.0
    Path:     /usr/libexec/docker/cli-plugins/docker-scan

Server:
 Containers: 2
  Running: 2
  Paused: 0
  Stopped: 0
 Images: 154
 Server Version: 28.1.1
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 Swarm: inactive
 Runtimes: runc io.containerd.runc.v2
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 05044ec0a9a75232cad458027ca83437aae3f4da
 runc version: v1.2.5-0-g59923ef
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 6.8.0-60-generic
 Operating System: Ubuntu 24.04.1 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 64
 Total Memory: 125.5GiB
 Name: XXXX
 ID: XXXX
 Docker Root Dir: /data/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  XXXX
  XXXX
  ::1/128
  XXXX
 Live Restore Enabled: false
 Default Address Pools:
   Base: XXXX, Size: 24

Thank you for the details. Can you also share the output of these commands?

Based on the docker info, that is not the output of a Docker in a snap package, but this will make it even more obvious that you have only one daemon installed.

But since I don’t use pass on Linux recently, I may not be able to give you a good answer, so you can also look for existing similar issues in the moby repository which is the base of Docker CE and if we can’t help you, and it turns out to be a bug, I believe that is where you can report bugs

I would also try to update Docker CE to the latest version just to see if it solves the problem locally. But I understand if you don’t want to update it if there is only a chance that it fixes the issue, so you could maybe try it in a virtual machine.

Hello Thank you for your reply.

$ snap list docker
error: no matching snaps installed

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.