1 kHz clock over long wire
So, the first problem will be that you need to drive that long cable! A 1km long piece of wire is simply a large load, and your microcontroller output will have a hard time changing the voltage on that reliably.
Think of the fact that the wire runs through its environment as a capacitor of wire to ground. So, you need a strong output driver.
You want that to drive a terminating load at the receiver that's relatively strong (so, maybe, 75 Ω to 120 Ω or something).
You'll want appropriate filtering at the receiver to extract the original clock.
You'll want cabling that is somewhat shielded, to not pick up 1000 m of radio antenna reception.
with many nodes connected to it
That means these many nodes need their own receiver. Can't put a strong terminator in each one of these (the load on the driver would get humongous), but if you don't, you'll get into terrible trouble with signal quality at these nodes.
To me, this sounds like you'd really want to build a multi-drop bus... like CAN!
Or, you'd want to receive, regenerate (Schmitt-Trigger?) and re-send the clock at every node – daisy-chaining them instead of using a linear bus.
will run up to 1000 m
Uh, that's really up the edge of what CAN still supports, at ridiculously low bit rates (and not all devices support the lowest CAN rate, IIRC; check that before you misinvest!)
Also note that for that length, you'd really want that CAN bus to run over shielded twisted pair or Coax. Ethernet cabling is cheap and can be bought on spools.
Considering your separate clock: you already have CAN; it's quite questionable you'd need to have a separate 1 kHz clock line along that: you have a way to communicate between nodes, in a manner that is way more accurate to time than a 1 kHz period, so just add a CAN-capable microcontroller to each node, and add a master that tells them regularly how many 1 kHz cycles have passed since the last clocking CAN message – the microcontrollers can then adjust an internal counter and generate a centrally disciplined 1 kHz locally.
That saves you cabling and gives you something that works remotely, if (and only if) your CAN bus runs reliably.
Other options would include adding self-designed bit-clock observers, that just observe the transmissions from your master to learn what bit clock that uses and to use that to generate the 1 kHz locally.
A 1000 m long bus with additional clocking functionality sounds like it's on the very edge of what you should be doing with a single CAN bus. I'd recommend segmenting that bus, if architecturally feasible. (Segmentation adds complexity, but it localizes faults and makes things easier to debug, often.)
At the very low baud rates that such a long CAN bus allows you to use, you might as well just go wireless and get rid of all the cabling. It's all a cabling vs hardware cost tradeoff, and restricted by the reliability you need (pro-tip: actually put numbers to that – even a wired bus isn't noise free, and you WILL need to think about what happens to your system if CAN bus packets get broken underway).
Personally: I'd not try to build my own bus system. For long haul, high-node count, people use use-case optimized field buses like PROFIBUS or EtherCAT, or just: Plain Ethernet! You can segment Ethernet with cheap Ethernet Switches, you can, but don't have to, run loss-safe protocols like TCP/IP on top of it, cabling with connectors is super cheap, it's well-tested.
So, your applications seems to be coordinating MCU times: That's definitely more of a job for periodic CAN messages than a 1 kHz clock. If you need accuracy, you might want to look at internet protocols like NTP and think about how to adapt them for a CAN system (the trick really is just having a roundtrip-measuring two-way exchange once in a while).
You really need to think hard about what you really mean by "simultaneous".
Over a span of 1000 meters, the concept does not extend down to the sub-ns regime. Heck, it would take a light pulse more than 3000 ns to traverse that distance, and an electrical pulse would take more like 5000 ns over an ideal transmission line. Your unshielded wire is going to be even slower than that because of the R-C delays created by the loading of all the nodes along the way.
Using GPS receivers at each node would at least get you down to the tens-of-ns range.
Have you considered sending a sine wave and using a comparator at the receiving end to reconstruct a squarewave?
at 1km, not much of a squarewave will remain as all the higher frequency components will be attenuated due to the transmission line