This was resolved in upstream cloud-init in 23.3, which moved
Before=systemd-user-sessions.service from cloud-init.service to cloud-
config.service to resolve LP: #2013403. That change was temporarily
reverted on Ubuntu due to a snap-related performance regression. On
Noble and newer, the snap regr
I think I solved my issue by doing `cd
/etc/systemd/system/multi-user.target.wants && sudo unlink ssh.service`.
Ths ssh service will anyway be restated by cloud-init later.
I can't garantee yet, and am not sure this is a good idea, will let you know.
--
You received this bug notification because
** Changed in: cloud-init (Ubuntu)
Importance: Undecided => Medium
** Changed in: cloud-init (Ubuntu)
Status: Confirmed => Triaged
** Also affects: cloud-init
Importance: Undecided
Status: New
** Changed in: cloud-init
Status: New => Confirmed
** Changed in: cloud-ini
I think the previous post is correct.
I got the same issue, and here is my '/var/log/auth.log' at that time
** Attachment added: "auth.log"
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1633453/+attachment/5050812/+files/auth.log
--
You received this bug notification because yo
I think the problem is that cc_set_passwords.py is doing an immediate
sshd service restart, and forcing sshd to get started immediately.
If that 'restart' is changed to a 'condrestart', it will only restart
the service if it is already running. That should continue to work in
any odd cases where
It's totally possible to fix things in the tools, but you have to fix in
all provisioning tools. My use case is first boot and is not about user
scripts, but proper configuration of SSH and SSH keys.
Looking a bit more, I see there is a Before=sshd.service for cloud-
init.service, so sshd should n
"Automatic provisioning tools usually waits for SSH to answer at the TCP
level and then expect things to work from here."
I'll let Scott handle the details, but as he mentioned by design runcmd
or user scripts run afterward anyway. To make sure that cloud-init
really is complete I happen to check
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.1
The restricted output to SSH stuff:
Jan 21 01:25:31 stress-test-23357 cloud-init[990]: [CLOUDINIT]
stages.py[DEBUG]: Running module ssh () with frequency
once-per-instance
Jan 21 01:25:31 stress-test-23357 cloud-init[990]: [CLOUDINIT]
handlers.py[DEBUG]: start: init-network/config-ssh: running
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: cloud-init (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1633453
Title:
Maybe the problem is that cloud-init restarts ssh after generating host
keys. Therefore, we are able to log just after that while cloud-init is
still running.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/b
So, a bit more on the above. So as far as I can see, you should not be
able to ssh into a system until cloud-init.service is done (preventing
you from getting in with stale ssh keys), but you most certainly can get
in before 'runcmd' or user scripts are all finished.
That is mostly by design.
--
I'm not sure how this would occur in xenial or yakkety.
cloud-init.service runs:
Before=sshd-keygen.service
Before=sshd.service
cloud-init.service is what runs the 'ssh' config module, which generates
ssh host keys and disables root. And 'ssh' runs after 'user-groups',
which sets the user-gro
13 matches
Mail list logo
