I’m missing a step here. I see a var called ssh, and an authorized key, but I don’t see where they’re seeing any method for the device to expose itself outside the NAT that’s in place on basically every consumer LAN.
This looks a lot more like the device fetches updates via SSH to a remote update server, and the authorized_keys entry is vestigial.
You're right it would be nice to see some more detail. Perhaps it requires sending a custom update when it reaches out via ssh or it does something wild like opening a reverse shell
Evidence of it opening a reverse shell would be wild, and should be possible to spot, if it’s happening, by monitoring what network traffic to that domain looks like.
Beyond that, companies being able to push changes via custom firmware is sort of the normal state of consumer IoT devices. And it doesn’t really imply the kind of broad “the whole engineering team can access my LAN” that the OP is speculating about.
Now, from a design standpoint, using SSH to pull firmware updates would be a bit of a wonky choice. But the world is full of wonky choices.
This looks a lot more like the device fetches updates via SSH to a remote update server, and the authorized_keys entry is vestigial.