cli: Non-root user "docker login" results in panic SIGSEGV segmentation violation

Description

Fresh install on Debian Buster. Using a non-root user who is a member of the docker group I started getting a panic when running docker login for the first time after install. This seems to be a new issue.

Steps to reproduce the issue:

1. Create a new user who is a member of the docker group
2. Run docker login

Describe the results you received:

$ docker login
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x55b37f2d0406]

goroutine 1 [running]:
github.com/docker/cli/cli/command.ConfigureAuth(0x55b380d12fe0, 0xc000505520, 0x0, 0x0, 0x0, 0x0, 0x0, 0x55b380c82401, 0xc0000812d0, 0xc000727968)
        /go/src/github.com/docker/cli/cli/command/registry.go:128 +0x46
github.com/docker/cli/cli/command/registry.runLogin(0x55b380d12fe0, 0xc000505520, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
        /go/src/github.com/docker/cli/cli/command/registry/login.go:123 +0x223
github.com/docker/cli/cli/command/registry.NewLoginCommand.func1(0xc0006a22c0, 0x55b381d1d5c8, 0x0, 0x0, 0x0, 0x0)
        /go/src/github.com/docker/cli/cli/command/registry/login.go:45 +0xcc
github.com/docker/cli/vendor/github.com/spf13/cobra.(*Command).execute(0xc0006a22c0, 0xc0006915c0, 0x0, 0x0, 0xc0006a22c0, 0xc0006915c0)
        /go/src/github.com/docker/cli/vendor/github.com/spf13/cobra/command.go:850 +0x462
github.com/docker/cli/vendor/github.com/spf13/cobra.(*Command).ExecuteC(0xc00050fb80, 0xc0006915c0, 0x1, 0x1)
        /go/src/github.com/docker/cli/vendor/github.com/spf13/cobra/command.go:958 +0x34b
github.com/docker/cli/vendor/github.com/spf13/cobra.(*Command).Execute(...)
        /go/src/github.com/docker/cli/vendor/github.com/spf13/cobra/command.go:895
main.runDocker(0xc000505520, 0x55b380c85120, 0xc000010028)
        /go/src/github.com/docker/cli/cmd/docker/docker.go:287 +0x1d3
main.main()
        /go/src/github.com/docker/cli/cmd/docker/docker.go:298 +0xf3

This also happens when I try to log into our private registry.

Describe the results you expected:

Being prompted for username/password info to log into the registry.

Additional information you deem important (e.g. issue happens only occasionally):

If I use Ansible to log into the registry, it works. Once .docker/config.json is created (either by hand or via Ansible) I can type docker login and I’ll get the usual username prompt. If I move the .docker dir and type docker login I get the panic again.

Output of docker version:

$ docker version
Client: Docker Engine - Community
 Version:           20.10.1
 API version:       1.41
 Go version:        go1.13.15
 Git commit:        831ebea
 Built:             Tue Dec 15 04:34:48 2020
 OS/Arch:           linux/amd64
 Context:           default
 Experimental:      true

Server: Docker Engine - Community
 Engine:
  Version:          20.10.1
  API version:      1.41 (minimum version 1.12)
  Go version:       go1.13.15
  Git commit:       f001486
  Built:            Tue Dec 15 04:32:45 2020
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.4.3
  GitCommit:        269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc:
  Version:          1.0.0-rc92
  GitCommit:        ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0

Output of docker info:

$ docker info
Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Build with BuildKit (Docker Inc., v0.5.0-docker)

Server:
 Containers: 2
  Running: 1
  Paused: 0
  Stopped: 1
 Images: 2
 Server Version: 20.10.1
 Storage Driver: overlay2
  Backing Filesystem: xfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Cgroup Version: 1
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk s
yslog
 Swarm: active
  NodeID: xv0jr9ztk2ilprmm7lpah16uk
  Is Manager: true
  ClusterID: n94lxrdxn8e5v2a8bjmupupum
  Managers: 3
  Nodes: 3
  Default Address Pool: 10.0.0.0/8
  SubnetSize: 24
  Data Path Port: 4789
  Orchestration:
   Task History Retention Limit: 5
  Raft:
   Snapshot Interval: 10000
   Number of Old Snapshots to Retain: 0
   Heartbeat Tick: 1
   Election Tick: 10
  Dispatcher:
   Heartbeat Period: 5 seconds
  CA Configuration:
   Expiry Duration: 3 months
   Force Rotate: 0
  Autolock Managers: false
  Root Rotation In Progress: false
  Node Address: 10.10.1.60
  Manager Addresses:
   10.10.1.60:2377
   10.10.1.61:2377
   10.10.1.62:2377
 Runtimes: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 269548fa27e0089a8b8278fc4fc781d7f65a939b
 runc version: ff819c7e9184c13b7c2607fe6c30ae19403a7aff
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
 Kernel Version: 4.19.0-13-amd64
 Operating System: Debian GNU/Linux 10 (buster)
 OSType: linux
 Architecture: x86_64
 CPUs: 1
 Total Memory: 987.2MiB
 Name: staging-docker01
 ID: 56GF:S23G:QA4Q:IPVK:ULMZ:LHUR:AWS5:AQSN:LW42:4DP5:QJ7B:XEAU
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false

Additional environment details (AWS, VirtualBox, physical, etc.):

This is a Proxmox VM but this also happens on hardware. I’ve tested it with other non-root users and get the same result.