If your lightbulb is running ssh not telnet it is assuming some source of entropy, or it may as well be running telnet. There has been some work on hardening handshakes on protocols where randomness might not be available that it could look at.
If the lightbulb is running SSH it's most likely running on a microcontroller which almost certainly has a built-in analog-to-digital converter, and thus can get entropy from thermal noise. Either sample a floating pin or an internal band-gap voltage reference should produce some bits of entropy.
Does that really need to be true? Protocols with fixed keys can skip Diffie-Hellman, right?
As such, is there an option to configure OpenSSH such that it has a fixed authorized_keys, and does the authentication handshake in the opposite order: first establishing that it can talk to the client by decrypting the messages the client is sending; and then parsing the client’s auth commands from said decrypted stream, where one SSH AUTH message might be “auth me using the very key we’re conversing over.”
If there is, I’m surprised IoT devices don’t go for it. If there isn’t... why not?
Now I'm in front of an actual PC let's explain a bit more
It's absolutely critical in SSH that we end up with a unique session ID which will be the output of a cryptographic hash function (these days maybe SHA-256) but obviously the input to that function must be secret. Everything in the higher level parts of SSH assumes that there is a secret unique session ID. The session ID stays the same for the lifetime of a connection, although you can run key agreement itself again if the connection is long-lived or moves a lot of data so that it's unwise to keep using the same symmetric keys.
If you do any variant of DH obviously this session ID is the end result of the first DH key agreement process and so it'll be different every time because you're using random numbers.
But if you want to add a "fixed asymetric keys" mode you're going to need to agree a secret session ID for each new connection... somehow.
At some cost you could pick at random and send it from one party to the other, but then we're exactly back where we started about how we're assuming we have a good source of entropy.
If we just pick any fixed value it might as well be 0000 0000 0000 0000 and so on then obviously a bad guy can break everything and we should have just used telnet.
> As such, is there an option to configure OpenSSH such that it has a fixed authorized_keys
At least you can override the default functionality with your own by utilizing the "authorized keys command". It basically allows you to create your own authorization scheme instead of the default "key in file means access granted"
