docker
docker context remote ssh not working in host to > non-rootfull remote setup
Description
when both host and remote have rootfull setup in place it works as expected: https://docs.docker.com/engine/install/linux-postinstall/#manage-docker-as-a-non-root-user meaning running commands without sudo while they are running as superuser anyway.
when the host is not rootfull seems to work but the behaviour is erratic sometimes askpassword prompt happens and no connection is made.
seems the only way it consistently works is when both host and remote are rootfull without sudo commands.
Reproduce
without rootfull using sudo commands:
# sudo docker create context --docker host=ssh://user@ip testremote
testremote
Successfully created context "testremote"
# sudo docker context use testremote
testremote
Current context is now "testremote"
# sudo docker ps
Cannot connect to the Docker daemon at http://docker.example.com. Is the docker daemon running?
if remote is non rootfull it works as expected, the daemon is running but requires sudo in the remote then fails.
Expected behavior
maybe prompt again for sudo password or allow sudo password in remote
docker version
Client: Docker Engine - Community
Version: 23.0.0
API version: 1.42
Go version: go1.19.5
Git commit: e92dd87
Built: Wed Feb 1 17:47:38 2023
OS/Arch: linux/amd64
Context: default
Server: Docker Engine - Community
Engine:
Version: 23.0.0
API version: 1.42 (minimum version 1.12)
Go version: go1.19.5
Git commit: d7573ab
Built: Wed Feb 1 17:44:45 2023
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.16
GitCommit: 31aa4358a36870b21a992d3ad2bef29e1d693bec
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
docker info
Client:
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.10.2
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.15.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: 11
Running: 8
Paused: 0
Stopped: 3
Images: 9
Server Version: 23.0.0
Storage Driver: overlay2
Backing Filesystem: btrfs
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 logentries splunk syslog
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 31aa4358a36870b21a992d3ad2bef29e1d693bec
runc version: v1.1.4-0-g5fd4c4d
init version: de40ad0
Security Options:
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.1.9-200.fc37.x86_64
Operating System: Fedora Linux 37 (Workstation Edition)
OSType: linux
Architecture: x86_64
CPUs: 16
Total Memory: 30.96GiB
Name: # removed by user
ID: # removed by user
Docker Root Dir: /var/lib/docker
Debug Mode: false
Registry: https://index.docker.io/v1/
Experimental: false
Insecure Registries:
127.0.0.0/8
Live Restore Enabled: false
Additional Info
if this is the desired behaviors it should be documented that context use over ssh does not work with sudo commands in remote
This worked for me, as per https://docs.docker.com/engine/install/linux-postinstall/
sudo usermod -aG docker $USER
newgrp docker
In the end I could run from my local machine:
docker --context <context> compose up -d
While this might not solve the issue, it might help as a workaround.
I had a similar problem with using docker-cli on my local machine and podman on the remote VM, I purged podman with docker engine on the remote and VM and docker context works like charms :)
