Same way you'd get the password? It's either a physical or virtual server you more or less control, in which case the siblings' answers apply. Otherwise, it's probably some kind of image or something someone else controls, in which case bake in or send them your public key or certificate (if you've got colleagues in the same situation as yourself).
The password needs to be generated somehow, right? Assuming you don't you use a pre-baked password that repeats across machines, you could replace the password generation and retrieval with deploying a public key instead.
The remote system must generate its own SSH private key; you could use that opportunity to deploy the authorized keys before sealing the system as read-only.
No, it's assuming a device running a ssh daemon with something mounted rw or user-modifiable[0] that can hold an authorized_keys file. A NetBSD embedded board that configures sshd with `AuthorizedKeysFile /sdcard/config/authorized_keys` would be fine, for instance.
[0] For example, you could let the user write their key to an SD card and then mount it ro on the device.
"One time, on first use, where absolutely necessary, and changing password immediately afterwards" seems a reasonable interpretation of "approximately never".
Same way you'd get the password? It's either a physical or virtual server you more or less control, in which case the siblings' answers apply. Otherwise, it's probably some kind of image or something someone else controls, in which case bake in or send them your public key or certificate (if you've got colleagues in the same situation as yourself).
Getting a password does not require modifying the system. Injecting a public key does.
The password needs to be generated somehow, right? Assuming you don't you use a pre-baked password that repeats across machines, you could replace the password generation and retrieval with deploying a public key instead.
The remote system must generate its own SSH private key; you could use that opportunity to deploy the authorized keys before sealing the system as read-only.
You can commonly deploy the device/server with the client's public key.
What if it's mass produced and sold in a store?
That's assuming the device runs GNU/Linux with / mounted rw. But not everything is a laptop or a desktop.
No, it's assuming a device running a ssh daemon with something mounted rw or user-modifiable[0] that can hold an authorized_keys file. A NetBSD embedded board that configures sshd with `AuthorizedKeysFile /sdcard/config/authorized_keys` would be fine, for instance.
[0] For example, you could let the user write their key to an SD card and then mount it ro on the device.
3 replies →
"One time, on first use, where absolutely necessary, and changing password immediately afterwards" seems a reasonable interpretation of "approximately never".
3 replies →
I'd use a base image with a baked-in SSH certificate allowed.
Fairly trivial to make, at least with NixOS.
This hinges on this being either a VM or some hardware you've set up yourself.
what other situation would you be in?
7 replies →
[dead]