Windows credential helper doesn't support passwords greater than 2,500 characters in length

[dougrday]

When authenticating Docker with AWS, the recommend practice from AWS is this:

aws ecr get-login-password | docker login --username AWS --password-stdin <registry>

When AWS SSO is enabled, the value returned from get-login-password is greater than 2,500 characters in length, which causes the credential helper to fail. I've tested with both the desktop helper and wincred helper, both of which fail with this message:

Error saving credentials: error storing credentials - err: exit status 1, out: 'The stub received bad data.'

This is a fairly blocking issue for Windows developers, as they cannot log into the Docker registry if the authentication secret is large enough.

[dougrday]

It looks like there are similar problems with Azure SSO: aws/aws-cli#5636 (comment)

[dougrday]

Also this: awslabs/amazon-ecr-credential-helper#229 (comment)

[Anthropic]

Curious is this new @dougrday ?
I started hitting this today, but I haven't tried since the company started using SSO a few months back.
Praying this worked in an old version I can switch to as I have just spent a whole day trying to get it working before I found this.

[dandobrescu]

@Anthropic I don't have any issues with the old version, but I guess you also saw that yourself. It only happens when using permissions generated through SSO, and only if docker uses Windows Credential Manager

[dougrday]

I haven't tried myself, but my teammates have reported that the 2.3.x versions don't exhibit this problem.

As a temporary workaround, I've created this credential helper that stored the SSO credentials in plaintext in Windows. Our SSO tokens are only valid for a few hours, so the window of risk of plaintext goes down, but I still consider this a workaround, not a solution.

If anyone needs a stop-gap to keep working, here it is: https://github.com/dougrday/docker-credential-plaintext

[Anthropic]

I got around it by deleting credsStore values from all docker config.json files (both in Windows and Ubuntu) it seems to work now. Obviously this issue being resolved would be the better option, thank you for your time 👍

[tjohanssonn]

I haven't tried myself, but my teammates have reported that the 2.3.x versions don't exhibit this problem.

As a temporary workaround, I've created this credential helper that stored the SSO credentials in plaintext in Windows. Our SSO tokens are only valid for a few hours, so the window of risk of plaintext goes down, but I still consider this a workaround, not a solution.

If anyone needs a stop-gap to keep working, here it is: https://github.com/dougrday/docker-credential-plaintext

Thank you very much for providing this temporary workaround.

I have my code inside WSL, and found that I also had to add the file extension in ~/.docker/config.json:

{
  "credHelpers": {
    "my-private-repo": "plaintext.sh"
  },
  "credsStore": "desktop.exe"
}

Note that this is the config file inside WSL. I took me a little too long to understand why docker complained about not finding it in the $PATH. The ".exe" on the credsStore should've given me a hint...

[stevemk14ebr]

This still occurs! Confirmed removing credStore entry fixes with sso

[SuchismitaGoswami]

I tried all the solution mentioned here. Nothing worked for me. Tried this workaround as below

  echo '{"auths": {"https://index.docker.io/v1/": {}}, "HttpHeaders": { "User-Agent": "Docker-Client/19.03.12 (windows)"}}' > ~/.docker/config.json
  aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 1234567890.dkr.ecr.us-east-1.amazonaws.com

It worked. Posting it here if anyone finds it useful

[erenken]

I tried all the solution mentioned here. Nothing worked for me. Tried this workaround as below

  echo '{"auths": {"https://index.docker.io/v1/": {}}, "HttpHeaders": { "User-Agent": "Docker-Client/19.03.12 (windows)"}}' > ~/.docker/config.json
  aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 1234567890.dkr.ecr.us-east-1.amazonaws.com

It worked. Posting it here if anyone finds it useful

This worked perfectly for me. Thanks!