ssh-import-id gives bad handshake

[Adam Niedzwiecki]

Ubuntu 20.04 server runs with user data as below, yet it raises the error from launchpad.net

2020-04-01 17:24:18,815 ERROR HTTPSConnectionPool(host='launchpad.net', port=443): Max retries exceeded with url: /~aniecki/+sshkeys (C
aused by SSLError(SSLError("bad handshake: Error([('SSL routines', 'tls_process_server_certificate', 'certificate verify failed')])")))
Cloud-init v. 20.4.1-0ubuntu1~20.04.1 running 'modules:config' at Wed, 01 Apr 2020 17:24:17 +0000. Up 42.20 seconds.

Apparently this is the error because the host time is not yet synch up, but the ntp is also set there,

#cloud-config

ntp:
  enabled: true
  ntp_client: chrony

users:
  - name: kevo
    primary-group: users
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    groups: users
    ssh_import_id: aniecki
    lock_passwd: true
    ssh_pwauth: false

[Paride Legovini (paride)]

Hello Adam and thanks for this bug report. Does chrony actually set the system time after a while, or is this a permanent failure of chrony as an NTP client? In other words, is chrony set up correctly and this is a race-like issue between chrony and ssh-import-id, or is chrony broken on the system after cloud-init set it up? Does it work with a different ntp_client (e.g. systemd-timesyncd)?

Could you please run `cloud-init collect-logs` on a system where you hit the issue and attach the generated tarball to this bug report?

Waiting for more information I'm setting this to Incomplete for the moment.

[Adam Niedzwiecki (aniecki)]

Hi Paride,

This should work even with this basic setup, or Ubuntu should explain in the examples provided - what in needed to work (ssh_import_id: aniecki)

#cloud-config

users:
  - name: kevo
    primary-group: users
    shell: /bin/bash
    sudo: ALL=(ALL) NOPASSWD:ALL
    groups: users
    ssh_import_id: aniecki
    lock_passwd: true
    ssh_pwauth: false

I have modified this example, thinking that adding a

ntp:
  enabled: true
  ntp_client: chrony

wil fix it, but no... The same.

Attached is the file asked.

Now to answer your question, I think the problem is not with chrony as it eventually setlles, but somehow with the way cloud init works, that the initial time is taken from a compilation of the kernel, and I do not know how to forced to be in sync once ssh_import_id fires. Were it in sync - I would think (ssh_import_id: aniecki) will work fine (no bad handshake)..

Please advise. Perhaps a small change to the user data config will resolve it.

Cheers,
Adam

[Adam Niedzwiecki (aniecki)]

Hi Paride,

On another occasion, I have run setup without ntp, and yes! It did worked. "Miraculously" just before ssh_import_id: aniecki, time was sync up, no need to even specify this ntp thing

ntp:
  enabled: true
  ntp_client: chrony

If required, I could send you the logs from the host with ssh import working,,,?

But why "yes" - don't know, who "no" don't know either.. If you could share the light - that could be great... but yes, sometimes it works!!

Thanks,
Adam

[Ryan Harper (raharper)]

This variability of networking related issues (ntp or ssh-import-id) comes from the network-config included in this system:

The logs show this was booted with NoCloud datasource and it provided a network-config. The network-config provided looks like this:

2020-04-01 17:23:50,725 - stages.py[INFO]: Applying network configuration from ds bringup=False: {'version': 2, 'ethernets': {'eth0': {'dhcp4': True, 'optional': True}}}

In particular, the "optional: true" means that netplan/networkd does *NOT* wait until the interface is up before proceeding. If your DHCP server does not respond faster than the time it takes cloud-init to invoke the ntp or ssh_import_id modules, then the connection will fail.

This looks like this is an raspberry-pi ubuntu image from the mmcblock device and the baked-in network-config that's optional.

If you know you have DHCP on the network where you're booting the pi, you can edit the network-config file on the config partition of the image and remove the optional: true setting; this will ensure that the system blocks until networking is up before continuing to boot allowing networking functions to work as expected.

[Ryan Harper (raharper)]

I'm marking this bug invalid, cloud-init is doing what it was told to do and it appears looks like the user-data config relies on networking but the network-config was marked optional.

Please move this bug state back to New if you have further questions or issues.

[James Falcon (falcojr)]

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3869