An OpenWrt router that connect to a remote OpenWrt host in a Wireguard site-to-site configuration. The Wireguard keys are old, and potentially compromised.
What is the best practices for changing the keys, without ending up losing access to the remote system.
Use wg genkey and wg genpsk to generate new private, public and pre-shared keys for interface private key and also peers and for the interface on the remote router. SCP the key to the remote router. SSH into the remote router, update /etc/config/network with the new keys and then restart network service? Proceed to update config file on the local router and reboot.
Generating config files for interface with an online tool and all peers and then importing them into LuCI?
Maybe to create a new interface with new keys and removing the old one afterwards?
I guess the system needs to be rebooted afterwards or at least:
uci commit network
service network restart
Are there any scripts that can be used to automate the process, or is a safer bet to run the commands myself and manually copying the results into the config files?
Usage of specific commands in conjunction with grep to use to find and edit the corresponding line in the config file and then copy the key from the newly generated key files?
Never!
Always create them yourself, on a trusted device and over a secure method of communication (ssh, vpn, etc.).
I would change the config file directly and reboot, but you can come up with safer approaches (as in reverting to the last working one, in case of trouble).
I agree with @slh's idea here - create the new keys and replace them on both routers at the same time. Then, reboot the remote router while you're still connected and finally the local one (if you reboot the local one first, you will be unable to reconnect to the remote).
Do you have someone on-site at the remote location? With attention to detail it should be possible to do this without any issues, but if something goes wrong, you'll want someone on the other end to help out. Two ways they can help:
If you trust them with the administration of the remote router, you can give them the password and the keys and such.
If you don't trust them fully, you can open a screen sharing session with them -- you'll setup such that you can see and control their screen and then you can connect to the router since that computer will be on the correct network (this assumes that you don't have local restrictions that would prevent access).
Thanks for the feedback!
I agree with @slh usage of online tools is bad practice even though the site says key generation is done locally. Better to use my approach described under #1.
Unfortunatley there are nobody technical enough on-site at the moment so I have to do it myself over the VPN connection.
The remote router has a public static IP. I can maybe temporary enable incoming SSH traffic on the WAN interface if something goes wrong I can connect that way and fix it.
While it's a bit of a yolo approach (without remote hands), it's imho still safer than adding an untested second interface with its own firewall rules, routing policies, etc. Better to keep the changes small (just the access credentials) and audited, rather than doing major open heart surgery on network/ vpn setup.
If you feel like it, this time would be better spent on a custom revert (init-)script that writes back the config after x minutes/ reboots, unless stopped (if the new config are confirmed working).
@slh That seem like a very good idea! My knowledge of scripting is very limited if you can guide me in the right direction I would be very interested.
With the aid of that kind of script I can first make a backup of /etc/config/network and then edit the original file by inserting the new keys. Commit the changes and/or reboot. The script gets executed at boot and if it is not stopped (by using the remote connection) in let's say 15 minutes the changes gets reverted from backup.
save that to a file (i.e. /root/network_failsafe.sh), give it execute permissions (chmod +x /root/network_failsafe.sh), and then add /root/network_failsafe.sh to rc.local.
From there, you simply need to reconnect to your remote router and immediately move the /etc/config/network.bak file somewhere else (i.e. mv /etc/config/network.bak /root/network.bak (this will cause the script that is already running to be unable to replace the new network file with the backup). And if you've gotten that far, you can then remove the line added to rc.local and you should be good. (keep in mind, the above script will still trigger a reboot, but that shouldn't be an issue)
If you are unable to reconnect...
on your local router, copy backup network file into place (cp /etc/config/network.bak /etc/config/network)
reboot the local router
wait 15 minutes, and reconnect via what will be the old (known good) network configs on each router.