to the assertation model.json file, but every time we try to ssh into the CORE device from the same virtual ubuntu desktop that has the ssh keys in our SSO snap store… it asks for a password every time. We can’t quite figure out how to get this to work. Are we missing something? Do we need to manually create a system user for this to work?
Are you importing a system-user assertion for the accounnt you want created when setting up the device?
The authority-id in the model definition really just controls what keys are trusted to control the configuration of the device rather than actually making a change on its own.
yes, you do, either via the interactive console-conf tool (the thing that starts on screen at first boot), with a system-user assertion imported from USB key), with a config snap or with a cloud-init configuration file in the image …
Thank you Ogra for the details. This is great info. I didn’t realize we needed to add a system user to the assertion file or via a cloud-init file, to the image itself before the build. I like the idea of a config snap. This seems like the most simple method maybe but I need to create a root user so I can connect with my ssh keys to dev test core os and our snaps we are building.
What would be the recommendation for ease of use and support?
Is there any step-by-step instruction or a walk thought on the system-user assertation method using a usb import or dropping the files into the .img itself? The article you linked explains what it is, but i’m unsure on what files go where and how it knows to look for the usb stick.
If you go the cloud-init route, you’ll need to build a custom gadget snap for your device (the setup process reads cloud.conf file from the gadget snap). If you’re already using a gadget snap, then this might be easy. If you’re relying on the Canonical supplied gadget snaps, then it might not be so appealing.
If you go the system-user assertion route, the assertion is not included in the image you flash to the device. Instead the assertion file should be named auto-import.assert, and stored on some removable media (e.g. a USB thumb drive) that is plugged into the device while it does it’s first boot setup. The idea is that you could flash a common image to a bunch of devices, and then configure them with different sets of assertions on first boot.
This page is probably a better place to start than the reference documentation page @ogra linked:
One other note: if you are using VMs rather than physical hardware, you need to make sure the volume containing the assertion looks like a removable device. With qemu/kvm, I’ve managed to get it to work with something like:
