> There are also mechanisms to preconfigure an image without using Imager. To set up a user on first boot and bypass the wizard completely, create a file called userconf or userconf.txt in the boot partition of the SD card; this is the part of the SD card which can be seen when it is mounted in a Windows or MacOS computer.

> This file should contain a single line of text, consisting of username:encrypted- password – so your desired username, followed immediately by a colon, followed immediately by an encrypted representation of the password you want to use.

> To generate the encrypted password, the easiest way is to use OpenSSL on a Raspberry Pi that is already running – open a terminal window and enter

     echo 'mypassword' | openssl passwd -6 -stdin

> This will produce what looks like a string of random characters, which is actually an encrypted version of the supplied password.

From the anouncement [0], under "Headless setup".

[0] https://www.raspberrypi.com/news/raspberry-pi-bullseye-updat...

That's great. It would be even greater if userconf.txt could also contain an ssh key after the first line and put that ssh key on the new user.

If you enable ssh or configure wifi settings using the Raspberry Pi Imager it creates the shell script firstrun.sh on the fat partition. This script is launched using the systemd.run option set in cmdline.txt. This script will enable the ssh service, copy over wifi settings to the ext4 partition, change cmdline.txt so it is no longer run and then reboot the pi. You could take this script and extend it to do anything you would like including copying over ssh keys.

hashed*

All I did was quote the article. If you want to be a pedant, you need to take it up with the Raspberry Pi Foundation. I don't think a one-word answer here on HN, is going to do a thing.

Differentiating between hashing and encryption is not pedantic. But sure, go ahead and keep telling newbies to encrypt their passwords.

Perhaps. But supplying a one-word correction which requires you to already understand the context fully to be able to interpret it, is difficult to see as anything but pointless pedantry, despite trying.

The only people to understand the comment, are the ones it won't help.

If you're running a headless setup I'd switch to Ubuntu. You can use cloud-init and set it all up just like a VPS.

Do sound, gpio and the onboard camera and display ports work out of the box?

This is what I do to bootstrap my Raspberry Pi's and its great.

There is a documented way to create a first user.

For all other kind of early sys admin tasks for a headless system you can mount the image to your Linux workstation and chroot into it using binfmt_misc and qemu-static. https://wiki.debian.org/RaspberryPi/qemu-user-static seems to describe it. (I haven't used those instructions, but my own 10 year old cheatsheet.)

FWIW, recent versions of the Imager have a hidden control panel where you can set the username and password and enable ssh etc.

https://9to5linux.com/raspberry-pi-imager-now-lets-you-contr...

They've provided a mechanism to do that. Similar to the SSH mechanism you already know about.

Maybe you can pipe a username and password, or maybe an ssh publickey, into the ssh file and it will create that user?

I wouldn’t be too worried, there will likely be a solution for “power users” who use the ssh file.

loopback mount and chroot into the fs, passwd. I'm sure there are probably easier ways though

I'm not sure that the arm binary "passwd" will run on x86/_64

QEMU and binfmt_misc should do the trick: https://wiki.debian.org/QemuUserEmulation

Ahh yes, there's qemu-arch64 but that's probably another rabbithole :)

I have used qemu-static a lot to work with ARM images and it works surprisingly well. That was before arm64 was a thing, but unless someone tells me the opposite I would not assume it makes a difference. The only thing that I remember not working is strace(1) because ptrace(2) is unimplemented. But even for that there is a special qemu option to get something similar.

What I've done for this in the past is create buildroot images that grabbed all the dynamic data from the first FAT partition (you can get it with blkid although on the Pi you can probably just hard code it.)