v2.14.1 — an ssh:// host that refuses says why

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/.ssh inside this container. Keys live on the host — ssh-copy-id wrote 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.