Skip to content
Latchkey

Docker "context use" - Cannot Connect to a Remote Docker Host in CI

A Docker context points the CLI at a specific daemon - including a remote one over SSH or TCP. After docker context use <remote>, every command targets that host, so an unreachable host, a bad SSH key, or simply the wrong context selected makes all commands fail to connect.

What this error means

After selecting a remote context, docker commands fail with error during connect / connection refused / Permission denied (publickey) against the remote endpoint. Switching back to the default (local) context makes them work again.

docker (remote context)
error during connect: Get "http://docker.example.com:2376/v1.45/version":
dial tcp: connect: connection refused
# or over SSH: ssh: handshake failed: ... Permission denied (publickey)

Common causes

The remote host is unreachable

The selected context targets a remote daemon (TCP :2376 or ssh://). If the host is down, firewalled, or the port is closed, every command fails to connect.

SSH key/auth not available in CI

An ssh:// context needs a usable key and known-host entry. A fresh CI shell without the key in an agent gets Permission denied (publickey).

The wrong context is selected

A leftover docker context use <remote> (or DOCKER_CONTEXT/DOCKER_HOST env) points the CLI at a host you did not intend, so local builds run against the wrong daemon.

How to fix it

Confirm and select the intended context

List contexts, check the active one, and switch back to local if a remote was left selected.

Terminal
docker context ls
docker context use default        # local daemon
# or target the remote deliberately:
docker context use prod-builder

Make the remote endpoint reachable

  1. For ssh://, load the key into an agent and add the host to known_hosts before any docker command.
  2. For TCP, confirm the port is open and TLS certs are present.
  3. Verify with docker context inspect <name> that the endpoint is what you expect.

How to prevent it

  • Set the docker context explicitly at the start of the job.
  • Provide SSH keys/known-hosts (or TLS certs) for remote contexts in CI.
  • Unset stray DOCKER_HOST/DOCKER_CONTEXT that override your intent.

Related guides

Tired of flaky CI? Latchkey auto-heals failed jobs and retries them for you. Start free →