An ssh:// host that refuses now says why
@famewolf set up key-based login between his three machines, tested it, added DOCKER_HOSTS, and lost two days to an instance that reported three managed hosts and could reach one.
The error, once it stopped being truncated, said Permission denied (publickey). Correct — and useless from where he was standing, because the keys did work.
They did, on the host. Docksentry runs in a container, and a container has its own filesystem: ssh-copy-id writes to /root/.ssh on the machine, and this image has no /root/.ssh in it at all. He is the second person to hit that, which is where a message should stop leaving it to be worked out.
So a refused ssh:// host now carries a sentence naming what is actually missing:
There is no
/root/.sshinside this container. Keys live on the host —ssh-copy-idwrote them to your own home directory, and a container has its own filesystem. Mount them read-only:-v /root/.ssh:/root/.ssh:ro
Three branches, and each is a check made at the moment of failure rather than an inference from the wording of the error: no .ssh at all, a mounted .ssh with no known_hosts, or both present — in which case the key really is being refused and it points at the remote authorized_keys instead.
What it deliberately does not do: blame keys for a connection refused on port 22, offer SSH advice to a tcp:// host, or attach a guess to an error it cannot place. A confident wrong hint is worse than none, because it sends somebody looking exactly where we pointed.