[09:12] how can I prevent cloud-init from starting openssh? the service is not enabled via systemd but gets started anyway when cloud-init runs [13:51] jbg: ssh.service is disabled? ssh is included and enabled in cloud images, but running cloud-init shouldn't affect it [14:01] falcojr: yes, sshd.service is disabled. the distro is arch. it seems that cloud-init effectively runs `systemctl restart sshd`, which starts sshd if it was not already running [14:01] after cloud-init completes, the service is still not enabled (would not start automatically), but it is started [14:02] i worked around it by stopping sshd after cloud-init completes, but it's annoying [14:10] have you tried masking the ssh service? [14:43] i could do that, but i do want sshd to run on some systems that use this image (on those systems i run systemctl enable --now sshd during startup) [14:44] i'd rather find out why something is starting it [14:44] it appears to be cloud-init so i guess it's some module [16:11] nothing in the codebase starts it. It's likely just the dependency chain. I'll admit I don't know systemd as well as I should, but IIRC a disabled service will still get started if another service depends on it === smoser1 is now known as smoser [16:48] the set user passwords module restarts ssh if it tweaks the config. [16:52] falcojr: if pw_auth is set, then cc_setup_passwords.py will update sshd config and do a service restart on ssh [16:59] jbg: if cloud-init restarts ssh, you can see the command it runs in /var/log/cloud-init.log ; [18:12] rharper: thanks, i'll check that out [18:13] and yes, it does look like setup passwords is doing it [18:14] and restarting ssh starts it if it's not already running, even if it's not enabled [18:14] i wonder if it could be changed to do systemctl try-restart [18:57] alternatively jbg you can not include ssh_pwauth in your user-config, or use ssh_pwauth: unchanged [19:00] jbg: I think using try-restart would also be an acceptable upstream change