Docker Feed Push - no basic auth credentials

Hi,

I have been attempting to use the proget docker feed, I have managed to Login:

docker login 100.100.00.00:88

Username: Admin

Password: Admin

That works fine.

I tag my image, but then when I push:

docker push 100.100.00.00:88/docker/testimage-one

I get the following response:

850772db4c8b: Preparing

5f70bf18a086: Preparing

d061ee1340ec: Preparing

d511ed9e12e1: Preparing

091abc5148e4: Preparing

b26122d57afa: Preparing

37ee47034d9b: Preparing

528c8710fd95: Preparing

1154ba695078: Preparing

no basic auth credentials

I have updated the docker daemon config so it does not require SLL, I have removed wincred from the docker config.json file and bypassed proxy setting for that ipaddress.
Is there anything else i need to configure on the proget server for this to work?

Product: ProGet
Version: 4.5.4

The error is coming from the client, and there is unfortunately no clue as to what would be causing it. The client is constantly in flux, and we're still new to troubleshooting client configuration problems, so nothing immediate is jumping out.

However a quick search for "docker no basic auth credentials" yields all sorts of similar situations using other private registries. For example, this issue reports that:

I think I might have found your issue and its a silly one. In my case the trailing slash (/) in the push step registry url was causing my auth problem.

Does not work :(
registry: https://<account-id>.dkr.ecr.us-east-1.amazonaws.com/

Works :)
registry: https://<account-id>.dkr.ecr.us-east-1.amazonaws.com

As soon as I took the trailing slash out my image push succeeded.

I found this by looking at the result on the docker login which adds an auth section in the ~/.docker/config.json file. The url for the associated with the ecr auth section did not include the trailing slash but the DockerHub one does. Docker likely uses the url as a key when looking up and retrieving an auth entry from the ~/.docker/config.json file.

So I would search using that same technique, and then troubleshoot in a similar manner. Please post what you find :)

I had to change 2 things when I had this problem on my windows computers.

1: I could not use the ip-address because of SSL errors - I had to use the host name.

2: I had to make sure that I logged on to the correct port. Your example was 88 in both login and push, but I forgot to use the port in the login command (I was using port 443).

Perhaps this will help someone having the same issue.