The auth team does not deal with container runtime issues AFAIK.  I do not know who owns our docker fork.

I'm thinking there's an older variant of Docker there, can you dig up the docker version on the machine?

# docker version
Client:
 Version:         1.13.1
 API version:     1.26
 Package version: docker-1.13.1-59.gitaf6b32b.fc27.x86_64
 Go version:      go1.9.6
 Git commit:      30c1ca9-unsupported
 Built:           Tue Jun 12 19:29:50 2018
 OS/Arch:         linux/amd64

Server:
 Version:         1.13.1
 API version:     1.26 (minimum version 1.12)
 Package version: docker-1.13.1-59.gitaf6b32b.fc27.x86_64
 Go version:      go1.9.6
 Git commit:      30c1ca9-unsupported
 Built:           Tue Jun 12 19:29:50 2018
 OS/Arch:         linux/amd64
 Experimental:    false
[root@localhost ~]# 
[root@localhost ~]# 
[root@localhost ~]# docker login -u random -p random
Error response from daemon: Get https://registry-1.docker.io/v2/: unauthorized: incorrect username or password


FWIW, when this behaviour is present, docker login  would fail "silently".  If it could not get authorization from the registry, it wouldn't raise an error and would just retain the credentials generated.  It did this under the assumption that that you'd work on getting your credentials straightened out on the registry.  If you tried to pull an image from the registry and your credentials were still not good, then the pull would fail.  It would only succeed if the credentials were valid.

The docker version is same but git commit id is different.

[root@master-0]# docker version
Client:
 Version:         1.13.1
 API version:     1.26
 Package version: docker-1.13.1-68.gitdded712.el7.x86_64
 Go version:      go1.9.2
 Git commit:      dded712/1.13.1
 Built:           Tue Jun 12 18:30:09 2018
 OS/Arch:         linux/amd64

Server:
 Version:         1.13.1
 API version:     1.26 (minimum version 1.12)
 Package version: docker-1.13.1-68.gitdded712.el7.x86_64
 Go version:      go1.9.2
 Git commit:      dded712/1.13.1
 Built:           Tue Jun 12 18:30:09 2018
 OS/Arch:         linux/amd64
 Experimental:    false
[root@master-0]# docker login -u random -p random
Login Succeeded
[root@master-0]# docker login -u sample -p sample
Login Succeeded
[root@master-0]#

Abhishek I've been trying to reproduce and have not been able to.  Can you please do the following?

1) Attach the output for `docker info`
2) Attach the contents of /etc/containers/registries.conf
3) Attach the contents of /etc/sysconfig/docker
4) If possible 'yum -y update docker` on the machine that's having problems and retry.

If handing some of this information is sensitive, please let me know.

Thanks!

Tom, any update on this?

No update yet.  I tried recreating locally without luck, then got sidetracked by other issues.  Need to circle back soon to this.

Abishek, I did forget to ask.  When you did the yum update, did the version change for docker?  If so, can you tell me what it is and include the output from "docker version" again please.

I have the exact same issue.

[root@xxxxxx .docker]# docker login -u random -p random
Login Succeeded


Containers: 3
 Running: 1
 Paused: 0
 Stopped: 2
Images: 8
Server Version: 1.13.1
Storage Driver: overlay2
 Backing Filesystem: xfs
 Supports d_type: true
 Native Overlay Diff: true
Logging Driver: journald
Cgroup Driver: systemd
Plugins:
 Volume: local
 Network: bridge host macvlan null overlay
 Authorization: rhel-push-plugin
Swarm: inactive
Runtimes: docker-runc runc
Default Runtime: docker-runc
Init Binary: /usr/libexec/docker/docker-init-current
containerd version:  (expected: aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1)
runc version: 5eda6f6fd0c2884c2c8e78a6e7119e8d0ecedb77 (expected: 9df8b306d01f59d3a8029be411de015b7304dd8f)
init version: fec3683b971d9c3ef73f284f176672c44b448662 (expected: 949e6facb77383876aeff8a6944dde66b3089574)
Security Options:
 seccomp
  WARNING: You're not using the default seccomp profile
  Profile: /etc/docker/seccomp.json
 selinux
Kernel Version: 3.10.0-862.9.1.el7.x86_64
Operating System: Red Hat Enterprise Linux
OSType: linux
Architecture: x86_64
Number of Docker Hooks: 3
CPUs: 2
Total Memory: 15.51 GiB
Name: cdllaap001
ID: KAXS:N2BW:2ZCG:56ZG:T5GQ:IYO4:P5YU:MUV2:DLPM:QNHY:UEYF:4AOV
Docker Root Dir: /var/lib/docker
Debug Mode (client): false
Debug Mode (server): false
Username: random
Registry: https://registry.access.redhat.com/v1/
WARNING: bridge-nf-call-iptables is disabled
WARNING: bridge-nf-call-ip6tables is disabled
Experimental: false
Insecure Registries:
 127.0.0.0/8
Live Restore Enabled: false
Registries: registry.access.redhat.com (secure), docker.io (secure)

--
# docker version
Client:
 Version:         1.13.1
 API version:     1.26
 Package version: docker-1.13.1-68.gitdded712.el7.x86_64
 Go version:      go1.9.2
 Git commit:      dded712/1.13.1
 Built:           Tue Jun 12 18:30:09 2018
 OS/Arch:         linux/amd64

Server:
 Version:         1.13.1
 API version:     1.26 (minimum version 1.12)
 Package version: docker-1.13.1-68.gitdded712.el7.x86_64
 Go version:      go1.9.2
 Git commit:      dded712/1.13.1
 Built:           Tue Jun 12 18:30:09 2018
 OS/Arch:         linux/amd64
 Experimental:    false

====

[root@cdllaap001 .docker]# cat /etc/*release*
NAME="Red Hat Enterprise Linux Server"
VERSION="7.5 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VARIANT="Server"
VARIANT_ID="server"
VERSION_ID="7.5"
PRETTY_NAME="Red Hat Enterprise Linux"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.5:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.5
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.5"
NAME="Red Hat Enterprise Linux Server"
VERSION="7.3 (Maipo)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="7.3"
PRETTY_NAME="Red Hat Enterprise Linux"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:7.3:GA:server"
HOME_URL="https://www.redhat.com/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 7"
REDHAT_BUGZILLA_PRODUCT_VERSION=7.3
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="7.3"
Red Hat Enterprise Linux Server release 7.5 (Maipo)
Red Hat Enterprise Linux Server release 7.5 (Maipo)
cpe:/o:redhat:enterprise_linux:7.5:ga:server

I've figured out what's going on, but I'm not sure how to fix things at the moment.  First off, Abishek and Akrams, try this command please:

docker login docker.io -u fake -p fake

This will force docker login to try logging into docker.io's /v2 registry which will return an access error.  Earlier on my machine I was logging into docker.io and getting the error as I'd modified my /etc/containers/registries.conf file to hit docker.io first, that's why I wasn't seeing the error. 

Then please try:

docker login registry.access.redhat.com -u fake -p fake

I tried this myself by explicitly stating the registries to use:

# docker login docker.io -u fake -p fake
Error response from daemon: Get https://registry-1.docker.io/v2/: unauthorized: incorrect username or password

# docker login registry.access.redhat.com -u fake -p fake
Login Succeeded

As noted in the docker info that you both provided me, the default registry you're both using is:

Registry: https://registry.access.redhat.com/v1/

Which is a v1 registry and it looks like it doesn't respond back with an unauthorized response.  This issue was noted in this Docker issue: https://github.com/moby/moby/issues/24093 (look for gitlab.com).

I further verified by using Podman on a Fedora server and saw the same behaviour:

# podman login docker.io -u fake -p fake
error logging into "docker.io": invalid username/password

# podman login registry.access.redhat.com -u fake -p fake
Login Succeeded!

I don't think there's any code to be changed in Docker to solve this, but rather the registry running on  registry.access.redhat.com/v1 should return an authorized like docker.io does in these situations.  I don't know who to talk to about that or how to pull that off.  Dan Walsh and Antonio Murdaca any idea how to do that or who to talk to?

Again even though the message is "Login Succeeded", the credentials are just stored in your config.json file and no access has or will be granted for them unless someone makes a "fake" user with the password "fake".

alrighty, seems clear that our registry is misbehaving then, it should reply with not authorized or it's going to confuse any client interacting with it (like docker, podman and the like).

This is not for the containers team.

Thanks a lot Tom. I got past the issue by using the "docker.io" option with the login command per the example you sent. It does look like a redhat bug.

Btw, the registry issue is going to be fixed hopefully. Whether, there's another "gotcha" in this bz. The gotcha is the default registry that we use for login is also set to redhat which is super misleading but I believe we can't fix that at this point.

registry.access.redhat.com does not have any authentication enabled at all, thus the /v2/ ping endpoint returns a 200 always.

(In reply to Patrick Easters from comment #18)
> registry.access.redhat.com does not have any authentication enabled at all,
> thus the /v2/ ping endpoint returns a 200 always.

alrighty, then, this BZ is all about:

- docker shipped in RHEL has a default additional registry set to "registry.accesss.redhat.com" in /etc/containers/registries.conf (docker info output to check as well)
- setting the above will cause "docker login" w/o any registry at the end to try and auth to "registry.access.redhat.com". Eventually, that goes through as well as no auth is enabled on that registry
- the current workaround is to explicitly use "docker login docker.io"
- afaict, this always worked like this so I believe we'll need documentation or a kbase to highlight what's in this BZ and where the misleading is.
- if this was not working like this in the past, we have a regression (Tom please make sure of it)

The other workaround is to add docker.io to your list of registries in the [registries.search] table in /etc/containers/registries.conf, either by itself or in the front of the list like:

registries = ['docker.io', 'registry.access.redhat.com']

or

registries = ['docker.io']

and remember to restart docker with `systemctl restart docker` before logging in again.  Docker login will try to log into the first registry in that list and will fail or complete based on the credentials provided.

Antonio, this is the behaviour from the past too, except the registry lookup was done in /etc/sysconfig/docker if a registry was not provided in the docker login command.  It's recommended that you pass in a registry to the docker login command and in fact the podman login command requires that.

(In reply to Tom Sweeney from comment #20)
> The other workaround is to add docker.io to your list of registries in the
> [registries.search] table in /etc/containers/registries.conf, either by
> itself or in the front of the list like:
> 
> registries = ['docker.io', 'registry.access.redhat.com']
> 
> or
> 
> registries = ['docker.io']

I wouldn't recommend the above as that's going to change the behavior pull/push work as well. Just using the registry host name as an argument to Docker login should do the trick. 

> 
> and remember to restart docker with `systemctl restart docker` before
> logging in again.  Docker login will try to log into the first registry in
> that list and will fail or complete based on the credentials provided.
> 
> Antonio, this is the behaviour from the past too, except the registry lookup
> was done in /etc/sysconfig/docker if a registry was not provided in the
> docker login command.  It's recommended that you pass in a registry to the
> docker login command and in fact the podman login command requires that.

After much email discussion, it was decided to make `docker login` require a server name would help lessen this issue.  The first BZ for that is: https://github.com/projectatomic/docker/pull/320

Note: if you use a v1 server that does not return an authorization error such as registry.access.redhat.com, you will still receive the "Login Succeeded" message when nothing realy happened.