"Timed out waiting for instance launch." when using cloud-init to configure SSH AllowUsers

[dennisvang]

Describe the bug

Instance launch times out when specifying a cloud-config that sets AllowUsers in sshd_config.d.

To Reproduce

1. create file my-cloud-config.yml:

   #cloud-config
   users:
     - name: myuser
       sudo:
         - ALL=(ALL) NOPASSWD:ALL
       ssh_authorized_keys:
         - <my-public-key>
   write_files:
     - path: /etc/ssh/sshd_config.d/ssh-custom.conf
       content: |
         AllowUsers myuser  

2. launch instance with this config:

   multipass launch --cloud-init my-cloud-config.yml -vvv

3. observe the resulting timeout:

   ...
   [2025-07-25T14:25:52.191] [info] [melodious-hairtail] process started
   Timed out waiting for instance launch.
   ...
   

Note

Actually it does work if I add the default ubuntu user to AllowUsers, so

AllowUsers myuser ubuntu

Expected behavior

I would expect this to work normally.

Also, based on the docs, I would expect there to be no default ubuntu user if it is not explicitly listed under users.

Logs

n/a

Additional info

• OS: Ubuntu 24.04.2 LTS

• CPU architecture or model: x86_64

• multipass version

  multipass 1.16.0
  multipassd 1.16.0

• multipass info

• multipass get local.driver

  qemu

Additional context
Add any other context about the problem here.

[dennisvang]

So there are actually two questions:

1. Why does multipass launch time-out if the default user (ubuntu) is denied ssh access?

2. Why is the default user (ubuntu) being created in the first place, given that we only define myuser?

   From the cloud-init docs:

   Default user creation:

   Unless you define users, you will get a 'ubuntu' user on Ubuntu systems with the
   legacy permission (no password sudo, locked user, etc). If however, you want
   to have the 'ubuntu' user in addition to other users, you need to instruct
   cloud-init that you also want the default user. To do this use the following
   syntax:
   users:
   - default
   - bob
   - ....
   foobar: ...

   users[0] (the first user in users) overrides the user directive.

   That does not seem to be working as expected.

   Also all the users-and-groups examples imply the default user should be skipped in our case:

   Example 3: Skip creation of the default user and only create [...]

   Looks similar to https://askubuntu.com/questions/1461894/cloud-init-always-adding-ubuntu-user

   The suggestions from don-t-create-any-default-user and override-default-user-config don't seem to work either.

Now I'm not so sure if this is supposed to be a multipass issue or a cloud-init issue.

UPDATE:

Just tried the same cloud-config file at an actual cloud provider, and there it worked as expected, without any issues.

Cloud provider and local system show the same version of cloud-init:

/usr/bin/cloud-init 25.1.2-0ubuntu0~24.04.1

[xmkg]

So there are actually two questions:

1. Why does multipass launch time-out if the default user (ubuntu) is denied ssh access?

2. Why is the default user (ubuntu) being created in the first place, given that we only define myuser?
   From the cloud-init docs:

   Default user creation:
   Unless you define users, you will get a 'ubuntu' user on Ubuntu systems with the
   legacy permission (no password sudo, locked user, etc). If however, you want
   to have the 'ubuntu' user in addition to other users, you need to instruct
   cloud-init that you also want the default user. To do this use the following
   syntax:
   users:

   • default
   • bob
   • ....
     foobar: ...
     users[0] (the first user in users) overrides the user directive.

   That does not seem to be working as expected.
   Looks similar to askubuntu.com/questions/1461894/cloud-init-always-adding-ubuntu-user
   The suggestions from don-t-create-any-default-user and override-default-user-config don't seem to work either.

Now I'm not so sure if this is supposed to be a multipass issue or a cloud-init issue.

UPDATE:

Just tried the same cloud-config file at an actual cloud provider, and there it worked as expected, without any issues.

Cloud provider and local system show the same version of cloud-init:

/usr/bin/cloud-init 25.1.2-0ubuntu0~24.04.1

Hi @dennisvang, sorry that you're experiencing this issue. I'll answer your questions below:

Now I'm not so sure if this is supposed to be a multipass issue or a cloud-init issue.

It's a Multipass issue.

1. Right now, Multipass relies on SSH connectivity to determine whether an instance is up or not, and it uses the "ubuntu" user to do that. So, that's why it fails to launch.

2. The "ubuntu" user doubles up as a management user, so I'm afraid it's not possible to ditch it entirely at this moment.

[dennisvang]

@xmkg Thanks for the quick and helpful response! 👍

Now I see this is actually mentioned very clearly in the troubleshooting docs:

If SSH doesn’t function properly in the VM, or Multipass is blocked from accessing it, your instance may need to be reconfigured or repaired.

• If the default user is not ubuntu, Multipass cannot connect. If you used a custom cloud-init config file, make sure that the default user is ubuntu.
• [...]

Sorry, not sure why I did not spot this earlier, despite going over the docs many times...

Perhaps this could also be mentioned in a more prominent place?

By the way, I think multipass is great! 🥇

[dennisvang]

@xmkg Am I correct in assuming that multipass also requires sshd to use the default port 22?

Launch times out while "Starting" if I configure another port in my cloud-config file (via sshd_config.d).

[xmkg]

@xmkg Am I correct in assuming that multipass also requires sshd to use the default port 22?

Launch times out while "Starting" if I configure another port in my cloud-config file (via sshd_config.d).

Yes, that's also correct.

[dennisvang]

Thanks again @xmkg

Another related problem I ran into is a consistent "timed out waiting for initialization to complete". After the timeout, multipass list showed that the instance did come online.

This was apparently due to my cloud-config file setting up fail2ban for SSH traffic.
From the fail2ban logs there was one private ip being banned, which, I assume, is from multipass.

The solution is to whitelist that specific private ip or private ip-range in the fail2ban jail config, e.g. ignoreip = 10.0.0.0/8.