You can commonly deploy the device/server with the client's public key.

That's assuming the device runs GNU/Linux with / mounted rw. But not everything is a laptop or a desktop.

[delayed]

I don't know. I come across old AP/routers where I've forgotten the login credentials and find myself hard resetting them with some regularly, one that's above "approximately never" anyway.

I'm presuming the hard reset is to a factory-assigned password.

Is that uniform across all devices, or device-specific?

Practice I've seen for some years now is to have a label on the device with admin/root password, which is presumably neither uniform across devices nor trivially-determinable from device characteristics (e.g., MAC address, sequential serial numbers, etc.).

I'd still consider that practice reasonably tolerable, though you should be keeping better tabs on assets and credentials.

It could be totally fine if you disable WiFi and connect physically. At least the first time for setup.

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.

So what do you do when the device has no long-term storage like an SD card?

Such a device is then simply not suitable for situations where the issues with SSH password authentication become relevant.

What kind of device runs sshd but has no persistent storage?

What if it's mass produced and sold in a store?

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?

Any device where you don't control the initial firmware, and the firmware doesn't support ssh keys. AP/Routers (consumer and commercial and industrial grade), Shared hosting with ssh but limited features (eg GoDaddy)...

For physical devices, you can usually connect them via a dedicated Ethernet cable right to your laptop, and set the initial password. They likely don't have the right network settings anyway to drop them right into the bigger LAN.

Otherwise I think you just prepare a certificate ahead of time, and scp it during the first connection, then immediately disable password-based access, or at least change the password. Any passive eavesdropping still needs to defeat the encryption somehow (no feasible ways are known now), even having seen the initial exchange.

If you have an active MITM attack, all bets are off, because the attacker could even grab the image with the pre-baked key you're sending, and copy or change the key. If this is not possible, then the pre-baked key would help. If your security is really important, don't use ther cheap GoDaddy's offerings with limited SSH.

Let's say you bought a router and now you want to log into it.

Then you connect physically and do whatever is necessary to prepare that router for your intended use.

Connect to what? It only has an ethetnet jack.

Your laptop, for instance.

Are you being intentionally difficult or have you just never bought and set up a router?

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.