Comment 5 for bug 1633453

Vincent Bernat (vbernat) wrote :

I attach a output of journalctl when the problem arises. From a client perspective, when I connect to the server too soon, I can get this trace from ssh:

OpenSSH_7.4p1 Debian-6, OpenSSL 1.0.2j 26 Sep 2016
debug1: Reading configuration data /dev/null
debug1: Connecting to 185.19.31.14 [185.19.31.14] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /tmp/tmp.MlvQm06wGu/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /tmp/tmp.MlvQm06wGu/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.4p1 Debian-6
ssh_exchange_identification: read: Connection reset by peer

This happens at 01:25:33Z.

My interpretation is that cloud-init is running in parallel with the remaining of the system. At some point, the system starts sshd, then cloud-init restarts it once it has modified its configuration. Since the client is in the early stages of the connection, it didn't get its own process and restarting ssh will close the connection unexpectedly.

This happens about 1 time out of 10 with automatic provisioning. Automatic provisioning tools usually waits for SSH to answer at the TCP level and then expect things to work from here.