/run/host-services/ssh-auth.sock doesn't work

[rdeusser]

• I have tried with the latest version of Docker Desktop
• I have tried disabling enabled experimental features
• I have uploaded Diagnostics
• Diagnostics ID:

Expected behavior

I have no idea because however Docker handles /run/host-services/ssh-auth.sock doesn't seem to be documented anywhere. The most I've been able to find is this which doesn't explain anything.

Actual behavior

I get this error message:

docker: Error response from daemon: invalid mount config for type "bind": bind source path does not exist: /run/host-services/ssh-auth.sock.

Information

• macOS Version: 12.6
• Intel chip or Apple chip: Apple (M1)
• Docker Desktop Version: v4.13.0

Output of /Applications/Docker.app/Contents/MacOS/com.docker.diagnose check

Starting diagnostics

[PASS] DD0027: is there available disk space on the host?
[PASS] DD0028: is there available VM disk space?
[PASS] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0013: is the $PATH ok?
[PASS] DD0003: is the Docker CLI working?
[PASS] DD0014: are the backend processes running?
[PASS] DD0007: is the backend responding?
[PASS] DD0008: is the native API responding?
[PASS] DD0009: is the vpnkit API responding?
[PASS] DD0010: is the Docker API proxy responding?
[PASS] DD0012: is the VM networking working?
[SKIP] DD0030: is the image access management authorized?
[PASS] DD0019: is the com.docker.vmnetd process responding?
[PASS] DD0033: does the host have Internet access?
[PASS] DD0018: does the host support virtualization?
[PASS] DD0001: is the application running?
[PASS] DD0017: can a VM be started?
[PASS] DD0016: is the LinuxKit VM running?
[PASS] DD0011: are the LinuxKit services running?
[PASS] DD0004: is the Docker engine running?
[PASS] DD0015: are the binary symlinks installed?
[PASS] DD0031: does the Docker API work?
[PASS] DD0032: do Docker networks overlap with host IPs?
No fatal errors detected.

Steps to reproduce the behavior

1. Run this minimal script which reproduces the error I get:

#!/usr/bin/env bash

docker build -t yolo:42 - <<EOF
FROM ubuntu:20.04

RUN apt-get update \
    && apt-get install -y --no-install-recommends \
    openssh-client

USER root
EOF

docker run \
       --rm \
       --interactive \
       --tty \
       --user="root" \
       --network="host" \
       --name="yolo" \
       --workdir $(pwd) \
       --mount "type=bind,source=/var/run/docker.sock,target=/var/run/docker.sock" \
       --mount "type=bind,source=$HOME/.ssh/known_hosts,target=/root/.ssh/known_hosts" \
       --mount "type=bind,src=/run/host-services/ssh-auth.sock,target=/run/host-services/ssh-auth.sock" \
       -e "SSH_AUTH_SOCK=/run/host-services/ssh-auth.sock" \
       "yolo:42" bash -c "ssh-add -L"

[rdeusser]

Okay I figured out that opening Docker from the terminal works: open -a Docker. Still, that's kind of obscure. Can we get this documented better somewhere?

[nicks]

open -a Docker means "open the Docker Desktop app"

If this failed before, but worked after you opened the app, that tells me that you didn't have Docker Desktop running before.

If you didn't have Docker Desktop running before, that tells me that your Docker CLI was probably talking to something else (e.g., a remote docker context, or an app masquerading as Docker). This would explain why /run/host-services/ssh-auth.sock didn't work, because that's a DD-specific thing.

Does that sound plausible?

[rdeusser]

I confirmed Docker for Desktop was running while this happened. Furthermore, if I quit the app and reopen via the icon in /Applications it doesn't work. It only works when I open it via terminal.

[git-rz]

docker-desktop seems to start it's own ssh-agent process in the case where there is none otherwise available (the normal case, where it may be started with the computer, or through finder.)

Here is how we can communicate with it, assuming it is the only ssh-agent process running:

SSH_AGENT_PID="$(pgrep ssh-agent)"
SSH_AUTH_SOCK="$(lsof -p "${SSH_AGENT_PID}" | awk '/ unix / {print $8}')
export SSH_AGENT_PID SSH_AUTH_SOCK

I agree with @rdeusser, starting ssh-agent in a terminal, and then docker-desktop from the same terminal is a really obscure workflow. As is this.

Please document the intended workflow.

[jeanpralo]

I am using 1password for ssh-agent and starting docker from terminal using open -a Docker vs starting from Spotlight does the trick, that is if I set the SSH_AUTH_SOCK to the right socket.

Now the reason seems to be that if you run Docker from Spotlight search of from Application directly by double clicking a new ssh-agent daemon is being started:

1. Start Docker via Application GUI
2. Check for ssh-agent:

$ ps wwaux | grep ssh-agent
xxx          28639   0.5  0.0 407982672   2496   ??  S     2:05pm   0:00.01 /usr/bin/ssh-agent -l

Whereas when you start from console after having set proper SSH_AUTH_SOCKS, no new ssh-agent is launched and we use the socket defined in the env variable:

$ export SSH_AUTH_SOCK=~/Library/Group\ Containers/2BUA8C4S2C.com.1password/t/agent.sock
$ open -a Docker
$ ps wwaux | grep ssh-agent
$

I have tried to set the SSH_AUTH_SOCK env variable using launchctl so that it is set by default for every app but does not do the trick. So if someone knows how to change env variable for apps launch via GUI feel free to help:

$ launchctl setenv SSH_AUTH_SOCK "~/Library/Group Containers/2BUA8C4S2C.com.1password/t/agent.sock" 

[docker-robott]

There hasn't been any activity on this issue for a long time.
If the problem is still relevant, mark the issue as fresh with a /remove-lifecycle stale comment.
If not, this issue will be closed in 30 days.

Prevent issues from auto-closing with a /lifecycle frozen comment.

/lifecycle stale

[lochmueller]

I confirmed this problem in our DEV envs. Restart Docker via CLI solved this, but it is not very cool to spread this information across multiple teams :-/

[docker-robott]

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

/lifecycle locked