5 ms·

> During device initialization, if the system identifies itself as a user terminal, the initialization script automatically writes 41 SSH public keys into /root

> During device initialization, if the system identifies itself as a user terminal, the initialization script automatically writes 41 SSH public keys into /root/.ssh/authorized_keys. Notably, port 22 on the UTA remains open to the local network at all times. Forty-one? So who does not have root access to "your" user terminal?

ronsor 1y ago
You, of course.
yonatan8070 1y ago
You, probably. On a more serious note, is this any different from ISPs having a remote management system for ISP provided routers? In terms of privacy, if SpaceX didn't have access to the user terminal, they could still just capture your traffic on the sattelite or the ground stations
- ronsor 1y ago
  If they have access to the router, they can capture local network traffic as well as internet traffic.
  - arghwhat 1y ago
    Note that such capture would be quite terrible for performance, not only requiring disabling any hardware offload (a great router might be able to route a few hundred megabit in large packets without offload assuming it doesn't do anything else) to make packets visible for capture, but it would also have to stream the output back to the adversary over the uplink as you would be limited to at most a few gigabytes of local, extremely slow storage, giving no means for local offline analysis... The risk of access to the router is more that they can access your network and touch unprotected and vulnerable things rather than active monitoring.
    - db48x 1y ago
      And most of that wouldn’t be useful. We use encryption for almost everything now for a reason. No, wiretaps on modern networks do not rely on backdoors, or even big labeled front doors like SSH, on individual subscriber devices. Instead it is built into the lower level routing. When an ISP gets a warrant (or whatever relevant document your country uses) they configure their routers to tag all of your traffic and mirror it to a server to be recorded. It’s entirely invisible to the subscriber, and highly automated.
      - tredre3 1y ago
        > And most of that wouldn’t be useful. We use encryption for almost everything now for a reason. The topic at hand is local network access. Some examples of things happening on your local network that you might not want Elon/ISP to see: - Many people have public shares on their NAS for things like media or family photos - Security cameras - Printers - If you're casting, the title of everything you watch is broadcasted on the network - Even if you're not casting, if you use an Android TV then the title of everything you watch is also broadcasted to the network by default - The list of all your devices - If you torrent things, then the hash of all your torrents is likely broadcasted to your local network (through Local Peer Discovery)
  - edf13 1y ago
    I sit my external routers (and Starlink) behind another network (DMZ).
- microtonal 1y ago
  On a more serious note, is this any different from ISPs having a remote management system for ISP provided routers? Maybe, but in more and more European countries, ISPs are required to accommodate you hooking up your own router/modem. E.g., I am on fiber and if I want to I can hook up my own router directly to fiber with an SFP+ module (I currently use the ISP-provided media converter, but my own router). Lots of tech users use their own Ubiquiti/OPNsense/OpenWrt routers, so no remote management. I wonder if this requirement applies to Starlink as well, since they are an ISP.
  - prajaybasu 1y ago
    As far as I'm aware, they are only required to allow you to use your own router. DSL tech is far simpler and it's always a combo unit so I could see a case where you would be allowed to bring your own DSL modem. But it just doesn't work like that for DOCSIS or GPON where the cable modems or ONTs these days do much more than just media conversion - SIP, PPPoE, IGMP, etc. even if they don't do Wi-Fi (so ISPs don't call them "routers" - except SingTel, which uses "ONR" to distinguish these units because they are in fact routers for IPTV and SIP). For all of those modems/ONTs, the firmware updates and the configuration for telephony/SIP and PPPoE are controlled by the ISP and also tested to work with their OLT or CMTS so it's just not possible for the ISP to guarantee support for any random modem or ONT. And to support the advanced configuration required these days for VoIP, IPTV, etc. on the "modem" or "ONT", ISPs basically have a backdoor called TR-069 which is really not too dissimilar to what Starlink has access to with their SSH keys. Even if you get "true" dumb modems or ONTs which do not do any routing whatsoever, the device on the other side still has full control over your dumb device via the DOCSIS provisioning process or GPON's OMCI. Starlink seems to be using SSH instead of building a whole protocol - because satellite tech is proprietary and doesn't need to work on other hardware. So, I find that it's highly unlikely that the ISP is officially required to support a user supplied modem, although I haven't consulted the EU laws on this. At most, I think using your own router would require the EU ISPs to provide bridge mode support, but that's not special to EU. However, the TR-069 backdoor is still active even with bridge mode. It can be fairly easy to stop TR-069 with a "dumb" ONT (usually SFP) but ISPs can and will notice that. Whether they allow it is up to them.
- amelius 1y ago
  I think the main problem is that they would have access to other traffic on your local network. But you can just add more hardware to isolate it.
- _joel 1y ago
  Is https://en.wikipedia.org/wiki/TR-069 https://en.wikipedia.org/wiki/TR-069 not available?
- mystified5016 1y ago
  In the US, ISPs are required to allow you to hook up your own modem. As long as your hardware is technically compatible with the network, you just give them your MAC address and plug it in. However, part of being compatible is that the modem bust be configurable and controllable by the ISP. The ISP will typically flash their own firmware to your modem without asking or telling you. The same applies to cell networks. The actual modem in your phone is running a binary blob provided by the network operator. This is done for very good reason, without control of all modems in the netork, the operator can't provide reliable service. A broken modem in the network screaming out non-compliant signals can screw things up for everyone. It's a necessary evil for the network operator to have privileged control over the hardware on their network. You solve this by treating your modem as a direct, untrusted, unprotected hole into the public internet. You also must assume that the ISP can inspect traffic on their network. To solve all of this, you put a firewall between it and your local network. I really don't think it's at all a problem for ISPs to have this level of control over customer modems. It is a problem when the ISP bundles the modem and router, but that's a different conversation. Just always use your own router.
znep 1y ago
I wonder who would be best equipped to see if any of those keys are traceable to individuals involved in special government affairs lately? There have been some good leaks...
niobe 1y ago
could simply be 41 instances of the same server in 41 regions, not necessarily a cause for concern. Starlink is a global service after all. I'd be more concerned if 41 instances were sharing one key.
- MrOwen 1y ago
  Is that normal? I would imagine that if I were managing such a large deployment, I would just use a CA for the keys and then issue CA signed private keys so that I don't need to add a bunch of random ones to authorized_keys
- overfeed 1y ago
  > I'd be more concerned if 41 instances were sharing one key. Dozens/hundreds/thousands of web servers servers can easily share one private key in a certificate, public keys offer even more options on sane designs. Directly authenticating 41 servers using ssh-keys is just poor, slap dash engineering.
  - gardenerik 1y ago
    Is it a better idea to share private keys? In case of server breach, you will have a much harder time, won't you?
    - overfeed 1y ago
      > Is it a better idea to share private keys It is not, amd I can't see how my earlier comment can be read as recommending that. This is a solved problem for private keys (using load balancers, for example) , so public keys are lower-hanging fruit than that. Edit: upon rereading, I cam see how the word "share" would be ambiguous in the context of if a private key. I meant "jointly make use of", rather than "distribute copies throughout the fleet". I have exited my root comment to make my meaning clearer.
    - ta1243 1y ago
      A better idea would be the terminal trusting one or two core certificate authorities and then those authorities creating time limited certificates when needed. So the terminal accepts "sshauthority1" Then the 41 remote sites contact sshauthority1 to get a 1 hour (10 minutes, 10 days, whatever) long certificate for "site18" If a remote site is compromised sshauthority1 no longer issues certificates, and within an hour (10 minutes, 10 days, etc) the remote site can no longer reach the terminals. Revoking a key from that many terminals (many of which will be offline) if one of the 41 keys is exposed is not trivial. Now if sshauthority1 is compromised then you've got the same issue with rotation (although can CRL it), but it's easier to secure one or two authorities than 41 keys.
sneak 1y ago
I’m a single user and my authorized_keys is 25 lines. I have different yubikeys in laptops, keys on iPads and iPhones, and secure enclave keys on macs. I imagine starlink has more than 1-2 sysadmins. I think a hundred pubkeys would be reasonable.
- tomalpha 1y ago
  It seems wrong that each individual sysadmin human in Space X would need to (a) login to my device remotely, and (b) require individual credentials to do so. Having some way to remotely push updates, and having some kinda of (preferably with your consent!) remote access might be reasonable, but I would expect that to be via some kind of intermediate gateway/app/something and not direct from a sysadmin’s individual account.
- ta1243 1y ago
  SSH Certificates is a far better approach even if that many users needed direct access. It's not 1990 any more.
  - sneak 1y ago
    Certificates are great, but not strictly necessary until you need to distribute thousands of keys. maintaining an authorized_keys text file is much simpler than running a CA.
- e2le 1y ago
  I can't imagine why that would be reasonable for an environment that demands a higher degree of security. I imagine the most ideal situation would be 1) minimising the number keys, 2) use hardware backed authentication or certificate based authentication, 3) lock up the private keys somewhere safe. The idea of 41 points of failure that can SSH into any starlink terminal is not appealing.
- e12e 1y ago
  I think a single trusted ssh certificate would be more reasonable...
e2le 1y ago
It would've being interesting if they had published those public keys.
steveharman 1y ago
[flagged]
adolph 1y ago
> So who does not have root access to "your" user terminal? Not to defend this but curious: Unless the terminal is attached to a local network that also has internet access, the satellite network would need to be traversed in order to connect using those keys, right? What kind of NAT/etc does Starlink use for satellite routers?
- 84634E1A607A 1y ago
  /56 DHCPv6 Prefix Delegation, and NAT44444 for IPv4 (192.168.1.x/24 for router, 192.168.100.x/24 for dish, 100.64.x.x for CGNAT, 172.16.x.x for Ground Station inner net, finally you are on the Internet).
doawoo 1y ago
I'm really perplexed by this choice... at my current employer we only deploy developer SSH keys to devices with DEV or QA firmware. Prod images are signed and have SSH entirely disabled. We have a separate piece of software to remotely access devices in prod to help diagnose engineering issues, where we can pull up a REPL, but that's under access control and gated by devops etc.
- CSSer 1y ago
  This is deeply ironic to me because this company is run by the same guy who has his underlings tearing through our government data, secretly building repositories with titles like NxGenBdoorExtract[0]. I don't trust this guy at all. [0]https://www.npr.org/2025/04/15/nx-s1-5355896/doge-nlrb-elon-musk-spacex-security https://www.npr.org/2025/04/15/nx-s1-5355896/doge-nlrb-elon-...
walrus01 1y ago
If I would have to guess this is more mundane than it first might appear, and probably a good security precaution. Rather than pushing out one, two or three ssh key pairs that have the private key pair running on some part of spacex CPE provisioning infrastructure that has access to millions of CPEs, they've got a more specific series of keys (perhaps by serial number of terminal produced, or production date?) where the management infrastructure has access to a much smaller number of terminals. Whatever they're doing with the private halves of those SSH keys can be compartmentalized.

ronsor 1y ago

You, of course.

yonatan8070 1y ago

You, probably. On a more serious note, is this any different from ISPs having a remote management system for ISP provided routers? In terms of privacy, if SpaceX didn't have access to the user terminal, they could still just capture your traffic on the sattelite or the ground stations

ronsor 1y ago
If they have access to the router, they can capture local network traffic as well as internet traffic.
- arghwhat 1y ago
  Note that such capture would be quite terrible for performance, not only requiring disabling any hardware offload (a great router might be able to route a few hundred megabit in large packets without offload assuming it doesn't do anything else) to make packets visible for capture, but it would also have to stream the output back to the adversary over the uplink as you would be limited to at most a few gigabytes of local, extremely slow storage, giving no means for local offline analysis... The risk of access to the router is more that they can access your network and touch unprotected and vulnerable things rather than active monitoring.
  - db48x 1y ago
    And most of that wouldn’t be useful. We use encryption for almost everything now for a reason. No, wiretaps on modern networks do not rely on backdoors, or even big labeled front doors like SSH, on individual subscriber devices. Instead it is built into the lower level routing. When an ISP gets a warrant (or whatever relevant document your country uses) they configure their routers to tag all of your traffic and mirror it to a server to be recorded. It’s entirely invisible to the subscriber, and highly automated.
    - tredre3 1y ago
      > And most of that wouldn’t be useful. We use encryption for almost everything now for a reason. The topic at hand is local network access. Some examples of things happening on your local network that you might not want Elon/ISP to see: - Many people have public shares on their NAS for things like media or family photos - Security cameras - Printers - If you're casting, the title of everything you watch is broadcasted on the network - Even if you're not casting, if you use an Android TV then the title of everything you watch is also broadcasted to the network by default - The list of all your devices - If you torrent things, then the hash of all your torrents is likely broadcasted to your local network (through Local Peer Discovery)
- edf13 1y ago
  I sit my external routers (and Starlink) behind another network (DMZ).
microtonal 1y ago
On a more serious note, is this any different from ISPs having a remote management system for ISP provided routers? Maybe, but in more and more European countries, ISPs are required to accommodate you hooking up your own router/modem. E.g., I am on fiber and if I want to I can hook up my own router directly to fiber with an SFP+ module (I currently use the ISP-provided media converter, but my own router). Lots of tech users use their own Ubiquiti/OPNsense/OpenWrt routers, so no remote management. I wonder if this requirement applies to Starlink as well, since they are an ISP.
- prajaybasu 1y ago
  As far as I'm aware, they are only required to allow you to use your own router. DSL tech is far simpler and it's always a combo unit so I could see a case where you would be allowed to bring your own DSL modem. But it just doesn't work like that for DOCSIS or GPON where the cable modems or ONTs these days do much more than just media conversion - SIP, PPPoE, IGMP, etc. even if they don't do Wi-Fi (so ISPs don't call them "routers" - except SingTel, which uses "ONR" to distinguish these units because they are in fact routers for IPTV and SIP). For all of those modems/ONTs, the firmware updates and the configuration for telephony/SIP and PPPoE are controlled by the ISP and also tested to work with their OLT or CMTS so it's just not possible for the ISP to guarantee support for any random modem or ONT. And to support the advanced configuration required these days for VoIP, IPTV, etc. on the "modem" or "ONT", ISPs basically have a backdoor called TR-069 which is really not too dissimilar to what Starlink has access to with their SSH keys. Even if you get "true" dumb modems or ONTs which do not do any routing whatsoever, the device on the other side still has full control over your dumb device via the DOCSIS provisioning process or GPON's OMCI. Starlink seems to be using SSH instead of building a whole protocol - because satellite tech is proprietary and doesn't need to work on other hardware. So, I find that it's highly unlikely that the ISP is officially required to support a user supplied modem, although I haven't consulted the EU laws on this. At most, I think using your own router would require the EU ISPs to provide bridge mode support, but that's not special to EU. However, the TR-069 backdoor is still active even with bridge mode. It can be fairly easy to stop TR-069 with a "dumb" ONT (usually SFP) but ISPs can and will notice that. Whether they allow it is up to them.
amelius 1y ago
I think the main problem is that they would have access to other traffic on your local network. But you can just add more hardware to isolate it.
_joel 1y ago
Is https://en.wikipedia.org/wiki/TR-069 https://en.wikipedia.org/wiki/TR-069 not available?
mystified5016 1y ago
In the US, ISPs are required to allow you to hook up your own modem. As long as your hardware is technically compatible with the network, you just give them your MAC address and plug it in. However, part of being compatible is that the modem bust be configurable and controllable by the ISP. The ISP will typically flash their own firmware to your modem without asking or telling you. The same applies to cell networks. The actual modem in your phone is running a binary blob provided by the network operator. This is done for very good reason, without control of all modems in the netork, the operator can't provide reliable service. A broken modem in the network screaming out non-compliant signals can screw things up for everyone. It's a necessary evil for the network operator to have privileged control over the hardware on their network. You solve this by treating your modem as a direct, untrusted, unprotected hole into the public internet. You also must assume that the ISP can inspect traffic on their network. To solve all of this, you put a firewall between it and your local network. I really don't think it's at all a problem for ISPs to have this level of control over customer modems. It is a problem when the ISP bundles the modem and router, but that's a different conversation. Just always use your own router.

znep 1y ago

I wonder who would be best equipped to see if any of those keys are traceable to individuals involved in special government affairs lately? There have been some good leaks...

niobe 1y ago

could simply be 41 instances of the same server in 41 regions, not necessarily a cause for concern. Starlink is a global service after all. I'd be more concerned if 41 instances were sharing one key.

MrOwen 1y ago
Is that normal? I would imagine that if I were managing such a large deployment, I would just use a CA for the keys and then issue CA signed private keys so that I don't need to add a bunch of random ones to authorized_keys
overfeed 1y ago
> I'd be more concerned if 41 instances were sharing one key. Dozens/hundreds/thousands of web servers servers can easily share one private key in a certificate, public keys offer even more options on sane designs. Directly authenticating 41 servers using ssh-keys is just poor, slap dash engineering.
- gardenerik 1y ago
  Is it a better idea to share private keys? In case of server breach, you will have a much harder time, won't you?
  - overfeed 1y ago
    > Is it a better idea to share private keys It is not, amd I can't see how my earlier comment can be read as recommending that. This is a solved problem for private keys (using load balancers, for example) , so public keys are lower-hanging fruit than that. Edit: upon rereading, I cam see how the word "share" would be ambiguous in the context of if a private key. I meant "jointly make use of", rather than "distribute copies throughout the fleet". I have exited my root comment to make my meaning clearer.
  - ta1243 1y ago
    A better idea would be the terminal trusting one or two core certificate authorities and then those authorities creating time limited certificates when needed. So the terminal accepts "sshauthority1" Then the 41 remote sites contact sshauthority1 to get a 1 hour (10 minutes, 10 days, whatever) long certificate for "site18" If a remote site is compromised sshauthority1 no longer issues certificates, and within an hour (10 minutes, 10 days, etc) the remote site can no longer reach the terminals. Revoking a key from that many terminals (many of which will be offline) if one of the 41 keys is exposed is not trivial. Now if sshauthority1 is compromised then you've got the same issue with rotation (although can CRL it), but it's easier to secure one or two authorities than 41 keys.

sneak 1y ago

I’m a single user and my authorized_keys is 25 lines. I have different yubikeys in laptops, keys on iPads and iPhones, and secure enclave keys on macs. I imagine starlink has more than 1-2 sysadmins. I think a hundred pubkeys would be reasonable.

tomalpha 1y ago
It seems wrong that each individual sysadmin human in Space X would need to (a) login to my device remotely, and (b) require individual credentials to do so. Having some way to remotely push updates, and having some kinda of (preferably with your consent!) remote access might be reasonable, but I would expect that to be via some kind of intermediate gateway/app/something and not direct from a sysadmin’s individual account.
ta1243 1y ago
SSH Certificates is a far better approach even if that many users needed direct access. It's not 1990 any more.
- sneak 1y ago
  Certificates are great, but not strictly necessary until you need to distribute thousands of keys. maintaining an authorized_keys text file is much simpler than running a CA.
e2le 1y ago
I can't imagine why that would be reasonable for an environment that demands a higher degree of security. I imagine the most ideal situation would be 1) minimising the number keys, 2) use hardware backed authentication or certificate based authentication, 3) lock up the private keys somewhere safe. The idea of 41 points of failure that can SSH into any starlink terminal is not appealing.
e12e 1y ago
I think a single trusted ssh certificate would be more reasonable...

e2le 1y ago

It would've being interesting if they had published those public keys.

steveharman 1y ago

[flagged]

adolph 1y ago

> So who does not have root access to "your" user terminal? Not to defend this but curious: Unless the terminal is attached to a local network that also has internet access, the satellite network would need to be traversed in order to connect using those keys, right? What kind of NAT/etc does Starlink use for satellite routers?

84634E1A607A 1y ago
/56 DHCPv6 Prefix Delegation, and NAT44444 for IPv4 (192.168.1.x/24 for router, 192.168.100.x/24 for dish, 100.64.x.x for CGNAT, 172.16.x.x for Ground Station inner net, finally you are on the Internet).

doawoo 1y ago

I'm really perplexed by this choice... at my current employer we only deploy developer SSH keys to devices with DEV or QA firmware. Prod images are signed and have SSH entirely disabled. We have a separate piece of software to remotely access devices in prod to help diagnose engineering issues, where we can pull up a REPL, but that's under access control and gated by devops etc.

CSSer 1y ago
This is deeply ironic to me because this company is run by the same guy who has his underlings tearing through our government data, secretly building repositories with titles like NxGenBdoorExtract[0]. I don't trust this guy at all. [0]https://www.npr.org/2025/04/15/nx-s1-5355896/doge-nlrb-elon-musk-spacex-security https://www.npr.org/2025/04/15/nx-s1-5355896/doge-nlrb-elon-...

walrus01 1y ago

If I would have to guess this is more mundane than it first might appear, and probably a good security precaution. Rather than pushing out one, two or three ssh key pairs that have the private key pair running on some part of spacex CPE provisioning infrastructure that has access to millions of CPEs, they've got a more specific series of keys (perhaps by serial number of terminal produced, or production date?) where the management infrastructure has access to a much smaller number of terminals. Whatever they're doing with the private halves of those SSH keys can be compartmentalized.