Closed ibiscardigan closed 6 months ago
Hi @ibiscardigan,
Multipass supplies the ssh key for the ubuntu
user inside the instance. Without this, Multipass would not be able to ssh into the instance to get status nor would multipass shell
and multipass exec
work. However, you should be able to ssh into the instance using testuser@...
. Is this not working?
That is correct, it doesn’t create the test user key in the authorised keys file. this means I can still access via the multi pass shell testvm command, but if I want to automate this via something like ansible which relies on that ssh access it creates a real issue.
Hi @ibiscardigan!
I tried your cloud-init file and it does what it is directed to do. I see a testuser
user and in /home/testuser/.ssh/authorized_keys
, I see the key there. Is this not what you are trying to accomplish?
I’m not getting that behaviour on my machines unfortunately. I have tried uninstalling and reinstalling multi pass to get this to work but despite my best efforts it’s not worked for me. Happy to try some other troubleshooting steps to better understand why multi pass behaviour in my machine has unexpected behaviour.
From within your Multipass instance, could you please provide the contents of /var/log/cloud-init.log
and /var/log/cloud-init-output.log
? This should show what cloud-init is doing here. Thanks!
Also that's from a new vm that I was trying to spin up, desired user is 'hamson', machine name is 'please' (I was getting desperate at this stage).
Looks like this is creating the problem:
Error: Cloud config schema errors: users.1: {'name': 'hamson', 'ssh_authorised_keys': ['ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9U7ibPiGbTNnAmDkcxa+/pTfIXt62/pxLN6Iu3fOR/rvXsvkfTKtsagymjPOIOerBusrV2aiakjH81uKVKNg3u4OwocvBoslGQRqoKLC1Ln7Tf30qItx2Nw0kJd+Ikl2YlLrrtwn9UtM8nACvT4hoWwKs/whJW6GWK3z4QniSBDQ9aPpFDJewhYOy4nF7OieTR/ADjkjiBoT8iW/msc6Ski6vlKOw0jme6O3Oj9H/tfRUwGcjqcwwBDl4iCGYf/ujWc+4uLdk/ehe8ewQxkyYPLL0PIjl0P0B6HA0PfRdTwNmy8V4DjV/yoD4vB4h9qnxZaHW9L5EUgpE2INtXao/ hamson'], 'sudo': 'ALL=(ALL) NOPASSWD:ALL'} is not of type 'string', users.1: {'name': 'hamson', 'ssh_authorised_keys': ['ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9U7ibPiGbTNnAmDkcxa+/pTfIXt62/pxLN6Iu3fOR/rvXsvkfTKtsagymjPOIOerBusrV2aiakjH81uKVKNg3u4OwocvBoslGQRqoKLC1Ln7Tf30qItx2Nw0kJd+Ikl2YlLrrtwn9UtM8nACvT4hoWwKs/whJW6GWK3z4QniSBDQ9aPpFDJewhYOy4nF7OieTR/ADjkjiBoT8iW/msc6Ski6vlKOw0jme6O3Oj9H/tfRUwGcjqcwwBDl4iCGYf/ujWc+4uLdk/ehe8ewQxkyYPLL0PIjl0P0B6HA0PfRdTwNmy8V4DjV/yoD4vB4h9qnxZaHW9L5EUgpE2INtXao/ hamson'], 'sudo': 'ALL=(ALL) NOPASSWD:ALL'} is not valid under any of the given schemas
It looks cloud-init does not like the schema you provided. That looks different than the example you pasted in the original description, so I can't really tell. All I can see in the logs you provided is:
2024-02-02 11:49:22,224 - schema.py[WARNING]: Invalid cloud-config provided: Please run 'sudo cloud-init schema --system' to see the schema errors.
exact same schema as before just new ssh key and user name:
users:
- default
- name: hamson
sudo: ALL=(ALL) NOPASSWD:ALL
ssh_authorised_keys:
- "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC9U7ibPiGbTNnAmDkcxa+/pTfIXt62/pxLN6Iu3fOR/rvXsvkfTKtsagymjPOIOerBusrV2aiakjH81uKVKNg3u4OwocvBoslGQRqoKLC1Ln7Tf30qItx2Nw0kJd+Ikl2YlLrrtwn9UtM8nACvT4hoWwKs/whJW6GWK3z4QniSBDQ9aPpFDJewhYOy4nF7OieTR/ADjkjiBoT8iW/msc6Ski6vlKOw0jme6O3Oj9H/tfRUwGcjqcwwBDl4iCGYf/ujWc+4uLdk/ehe8ewQxkyYPLL0PIjl0P0B6HA0PfRdTwNmy8V4DjV/yoD4vB4h9qnxZaHW9L5EUgpE2INtXao/ hamson"
Well, in the latest cloud-init you posted, I think cloud-init may prefer American English :zany_face: since the key is ssh_authorized_keys
(with a z
instead of s
in authorized). See if that helps the current issue. I do see in the original example, you had z
, but that one does work for me.
Interesting, when I recopied the template from the guides including using a z (good old freedom English) I didn't get the same Invalid cloud-config error despite the fact it still hadn't provisioned the ssh key. All relevant files attached: cloud-init.log cloud-init-output.log
cloud-init:
#cloud-config
users:
- default
- name: hamson
sudo: ALL=(ALL) NOPASSWD:ALL
ssh_authorized_keys:
- "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzQVJnNSJA8SzDFdcgKylL9OPsT30jW+fypMFuq2kOI7W8MOVYGK7GGJQB2mnzEpsPMCghgv+KptQyyyZP28NhOCmGV2vGqXaliAVgLHuyvCaLr1N3p4rPKQ3XCtABhDW1GB3MWGw6kXPQ19UiD19c6hxmJk+G0azDvWVajF8UPLZs/407taBZcTvg5u8ArzpIORzfiQ9SsA7ANDC5zulfMiW9ywSkveszS5Qm63zco17wuch7mNqKw1OnZUZWWtmi5GkwTES67b4s8lSAcwTB6jrlZN1YHQ+fm2QM1oRaY31kRqqxjYqQmRWi8fvBTvsw5Puj0TRdMKQz+DKrTt8n hamson"
write_files:
- content: Validated Run | "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzQVJnNSJA8SzDFdcgKylL9OPsT30jW+fypMFuq2kOI7W8MOVYGK7GGJQB2mnzEpsPMCghgv+KptQyyyZP28NhOCmGV2vGqXaliAVgLHuyvCaLr1N3p4rPKQ3XCtABhDW1GB3MWGw6kXPQ19UiD19c6hxmJk+G0azDvWVajF8UPLZs/407taBZcTvg5u8ArzpIORzfiQ9SsA7ANDC5zulfMiW9ywSkveszS5Qm63zco17wuch7mNqKw1OnZUZWWtmi5GkwTES67b4s8lSAcwTB6jrlZN1YHQ+fm2QM1oRaY31kRqqxjYqQmRWi8fvBTvsw5Puj0TRdMKQz+DKrTt8n hamson"
path: /tmp/test.txt
authorized-keys:
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDqPtuU0jc1xaPo5VhO5g/zvqx7mfUXXQRK3yC7prUW636hOhSvh31gLVwW8Sf84ph5q/Ig5CQvWtx4P2MRb9u4ywChqVEttB3I4WTifjS7v+nD3nVBDErpxVi5Vw2h4G+gFTlKLitmfDvyPwRlHWPlpyY7a0UPC2aPwsVx2mdKBHg8VwadtDc4PBdxl3GFGilX+AAh9pOYreJIh8VJO21sIHK8j5RB/iydcWDRAeZllHcQ3rVUPb7CooJKErQCnVUGcNJjHs0pLKh6wUOuuFyKUWCqmrmklm/iRbso1vhWa7XUzHIQhnA7ce4OgsfQVUuKoSja42AV/MrM/C7Ok6AT ubuntu@localhost
I see in cloud-init.log
that cloud-init wrote the key out:
2024-02-05 20:37:41,358 - util.py[DEBUG]: Writing to /home/hamson/.ssh/authorized_keys - wb: [600] 388 bytes
Are you saying that key is not in the instance?
Ahhhh, I think ive found where my troubleshooting has been going askew, when I was logging into the Multipass vm via shell I was assuming it was taking me to the new user and not thinking to valid I was actually in the /home/hamson dir before looking at the authorised keys file. Im happy you close this for now as I see the file there and the problem clould be (is likely to be) on my Mac side trying to authenticate into the vm.
Thank you so much for your help, I learnt a lot
Hi @ibiscardigan!
Glad you are working it out! Please let us know if you any issues with Multipass.
I had this issue, and realised that the file path for --cloud-init
parameter was incorrect. Correcting the file path fixed it.
Using Multipass in Windows, the incorrect path:
multipass launch docker ... --cloud-init infrastructure/multipass/cloud-init.yaml
Correct one:
multipass launch docker ... --cloud-init .\infrastructure\multipass\cloud-init.yaml
Description I'm creating an ubuntu vm on MacOs using Multipass. When I pass the --cloud-init configuration for some reason it generates an unexpected ssh-rsa key for ubuntu@localhost but not for my defined user. this means I can't ssh into the new vm.
To Reproduce
users:
write_files:
Expected behavior I would expect the provided ssh_rsa key for test user to exist and thus be able to ssh into the vm
Logs
Additional info
multipass version
: 1.13.0+macmultipass info --all
:Name: testvm State: Running Snapshots: 0 IPv4: 192.168.64.29 Release: Ubuntu 22.04.3 LTS Image hash: dddfb1741f16 (Ubuntu 22.04 LTS) CPU(s): 1 Load: 0.01 0.01 0.00 Disk usage: 1.4GiB out of 7.7GiB Memory usage: 141.2MiB out of 962.3MiB Mounts: --
multipass get local.driver
: qemuAdditional context Add any other context about the problem here. Originally I was running this via ansible and has assumed there was an ansible issue but after I added the write file block to verify its getting the right arg it became clear this appears to be a Multipass issue.