Not necessarily, although this unlock via ssh is a common/popular setup.
This is all customizable, through initramfs and crypttab, and there’s various documented common setups.
Basically, because luks/cryptsetup allows managing multiple key slots for each volume, you can have a lot of flexibility over how you manage these keys. You can add/remove additional passwords and none of this requires re encrypting or rewriting data.
For example, if reboots are a concern, you could keep a password(key) on a flash stick that is read automatically on boot, such that it will unlock spinning HDDs and NVMe drives.
That will still allow you to discard dead/semi broken disks safely, without the risk of leaking data in case drives come back to life after being powered off for a while or after being moved or in case the drive is ever miraculously repaired, but it will not impede your reboots.
In case your flash stick with a password dies or the data is corrupted, you could leave yourself one or more additional ssh password entry backdoors, that let you type-in a key.
Obviously, if someone breaks in and steals both the encrypted drives and the flash stick and knows what they’re doing - then the data you’ve been storing will be compromised. Because, they can boot up without having you ssh in.
You could also come up with other schemes/set up keys with limited lifespan, etc etc, ssh + flash stick approaches are the most popular however. Some folks use TPMs as well.
Also, in general, the kernel has a keyring that luks/cryptsetup can use, so that if you have a setup with multiple encrypted disks and ssh, you typically only need to type in a key once for multiple devices.
Also, lots of people just use an ssh client on their phones to unlock their servers after a reboot, and typically the way this ssh is setup is that you identify with a private/public ecdsa key, but instead of being logged into some temporary environment with a shell, you just get a password prompt and are disconnected as soon as you enter a password.