juju ssh fails to connect when host keys have been changed (until the machine agent is restarted)
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Canonical Juju |
Triaged
|
Low
|
Unassigned | ||
Bug Description
When trying to connect to a machine with juju ssh, it might fail with this error:
$ juju ssh 6
ERROR cannot connect to any address: [10.0.5.26:22 my.host.name:22]
Enabling debug gives a lot more details, including:
12:26:57 DEBUG juju.network.ssh reachable.go:110 host key for 10.0.5.26:22 not in our accepted set: log at TRACE to see raw keys
12:26:57 DEBUG juju.network.ssh reachable.go:110 host key for my.host.name:22 at 10.0.5.26:22 not in our accepted set: log at TRACE to see raw keys
12:26:57 DEBUG juju.network.ssh reachable.go:159 dial 10.0.5.26:22 failed with: dial tcp 10.0.5.26:22: i/o timeout
12:26:57 DEBUG juju.cmd.
We should be able to tell juju to either update or remove SSH host keys from its internal database in case there's been a voluntary change of these on a machine.
Also, the error message should be clearer and tell the user this is a host keys trust issue.
As a workaround, it's possible to juju ssh --no-host-
Thanks
| description: | updated |
| Changed in juju: | |
| status: | New → Confirmed |
| John A Meinel (jameinel) wrote | #1 |
| Changed in juju: | |
| importance: | Undecided → Medium |
| milestone: | 2.9.1 → 2.9.13 |
| status: | Confirmed → Triaged |
| tags: | added: bitesize |
| James Simpson (jsimpso) wrote | #2 |
| Changed in juju: | |
| milestone: | 2.9.13 → 2.9.14 |
| Changed in juju: | |
| milestone: | 2.9.14 → 2.9.15 |
| summary: |
- juju ssh fails to connect when host keys have been changed + juju ssh fails to connect when host keys have been changed (until the + machine agent is restarted) |
| Changed in juju: | |
| importance: | Medium → Low |
| Changed in juju: | |
| milestone: | 2.9.15 → 2.9.16 |
| Changed in juju: | |
| milestone: | 2.9.16 → 2.9.17 |
| Changed in juju: | |
| milestone: | 2.9.17 → 2.9.18 |
| Changed in juju: | |
| milestone: | 2.9.18 → 2.9.19 |
| Changed in juju: | |
| milestone: | 2.9.19 → 2.9.20 |
| Changed in juju: | |
| milestone: | 2.9.20 → 2.9.21 |
| Changed in juju: | |
| milestone: | 2.9.21 → 2.9.22 |
| Changed in juju: | |
| milestone: | 2.9.22 → 2.9.23 |
| Changed in juju: | |
| milestone: | 2.9.23 → 2.9.24 |
| Changed in juju: | |
| milestone: | 2.9.24 → 2.9.25 |
| Changed in juju: | |
| milestone: | 2.9.25 → 2.9.26 |
| Changed in juju: | |
| milestone: | 2.9.26 → 2.9.27 |
| Changed in juju: | |
| milestone: | 2.9.27 → 2.9.28 |
| Changed in juju: | |
| milestone: | 2.9.28 → 2.9.29 |
| John A Meinel (jameinel) wrote | #3 |
| Changed in juju: | |
| milestone: | 2.9.29 → none |
| tags: | added: canonical-is |
Digging internally, it looks like the host keys are checked on machine agent start. So one workaround should be to just bounce the machine agent (juju run --machine 10 systemctl restart jujud-machine-10).
I think we could treat host key checking (where we got valid keys but they didn't match our records) at something higher than DEBUG.