Docker-compose: ssh agent forwarding

[fabiofdsantos]

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

Information

I'm unable to get ssh-agent working inside the container. However, it works properly with docker run -it -v....

• macOS Version: 11.1 (Big Sur)
• Docker for Mac: 3.1.0

Diagnostic logs

2021-01-28 23:04:10.683155+0000  localhost com.docker.backend[13748]: 
grpcfuseClient.Add(XXXXXXX, /my-app-php, [host=,VM=php-sync,dst=/home/XXX/my-app,
option=nocopy host=/private/tmp/com.apple.launchd.EO2rUUToAS/Listeners,
VM=/host_mnt/private/tmp/com.apple.launchd.XXXXX/Listeners,dst=/run/host-services/ssh-auth.sock,option=rw])

Output

Host:

$ ssh-add -l
4096 SHA256:XXXXXXXXX XX@XX. (RSA)

Container:

Cloning into '/home/XXX/XXX'...

git@github.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights and the repository exists.

docker-compose.yml

version: "3"
services:
  php:
    build:
      context: ./.docker
      dockerfile: php.dockerfile
      args:
        - PROJECT_NAME=my-app
        - PROJECT_PORT=8081
        - XDEBUG_HOST=${DOCKER_GATEWAY_HOST:-host.docker.internal}
        - XDEBUG_PORT=9003
    container_name: my-app-php
    hostname: my-app-php
    volumes:
      - /run/host-services/ssh-auth.sock:/run/host-services/ssh-auth.sock
      - php-sync:/home/XXX/my-app:nocopy
    environment:
      - SSH_AUTH_SOCK=/run/host-services/ssh-auth.sock
    ports:
      - 8081:8081
networks:
  default:
    external:
      name: dev-network
volumes:
  php-sync:
    external: true

php.dockerfile

FROM php:7.4-fpm-alpine3.12
(...)
RUN apk add    \
  git        \
  openssh    \
(...)

USER myUser

CMD ["/usr/bin/entrypoint"]

[docker-robott]

Issues go stale after 90 days of inactivity.
Mark the issue as fresh with /remove-lifecycle stale comment.
Stale issues will be closed after an additional 30 days of inactivity.

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

If this issue is safe to close now please do so.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle stale

[voxmaster]

Hey! Same problem here. SSH agent forwarding stops working.
Documentation is gone too: https://docs.docker.com/docker-for-mac/osxfs/#ssh-agent-forwarding.
MacOS 11.4
Docker for Mac v3.5.2.
Compose 1.29.2

UPD:
eval $(ssh-agent -s) command breaks magic of /run/host-services/ssh-auth.sock. To fix this - reboot your Mac and run ssh-add command once more

[jsperezg]

Any update on this topic?

[niksy]

Also looking for the solution. It seems related to running image as non-root user:

That works for Dockerfile and docker-compose if a user is root and with some adjustments in Dockerfile for non-root.
When a user is non-root in the image and we use it in docker-compose with a mounted socket in volume, as explained https://docs.docker.com/docker-for-mac/osxfs/#ssh-agent-forwarding
the issue is that socket is owned by root and not accessible by the inner user from the image.

Is there any solution if we’re running image as non-root user? Currently only feasible solution is to brute-force /run/host-services/ssh-auth.sock with chmod 777; that’s probably okay in development environment, but security issue in any other situation.

[twelvelabs]

There are a few different (but related) issues w/ SSH agent forwarding in Docker for Mac:

• As noted here, if you're using a non-root user in the container they will not have access to /run/host-services/ssh-auth.sock. I'm not a security expert, but it seems like DFM should catch this and set usable permissions on the socket.
• DFM does not respect a user-supplied $SSH_AUTH_SOCK. It appears to be reading the var on startup (i.e. before it's customized by the user), or is preferring the value from launchctl getenv. Either way, if you're using a newer version of openssh (for example, to use FIDO2 resident keys) then it's likely that DFM is referencing the wrong socket.

Given that the error message from openssh is similar for both issues, it's very painful to get agent forwarding working when using a YubiKey (though I guess that shouldn't be surprising 🙄).

To get things working for me, I ended up:

• Symlinking the default socket created by launchd to point to the one created by the upgraded openssh - as per this suggestion. One alternative was to launch DFM from the terminal (so the customized $SSH_AUTH_SOCK would be picked up), but the symlink is a more holistic solution.
• Running this command from on a cron to ensure that any non-root containers will always be able to access forwarded sockets. I hadn't considered changing the socket permission in the entry point though. I may end up going that route for better portability.

Hope this summary helps any future travelers - good luck 👋.