My old hard drive failed, and I didn't have a backup. I had to replace the HDD. I have now lost my old SSH key.
I need to add my new SSH key to my 2 droplets. These droplets have been live for over 6 months.
Is it possible?
Please do not suggest adding an SSH key that requires logging into the server. That's impossible, as I don't have my old SSH key.
What options do I have?
You have two options. Unfortunately both will require some brief downtime for your droplets.
1.) Create a snapshot of the droplet and re-deploy it. If you power off your droplet, create a snapshot and re-deploy a new droplet from the snapshot you can add your key when the new droplet is created and get access to the new droplet with all your files and configuration in place (but a new IP address).
2.) Open a ticket with our support team. They can reboot your droplet to our Recovery ISO. This is a live Debian environment that will allow you to access your droplet via the console in the control panel, mount your disk and make any needed changes within your filesystem.
I would also recommend setting a root password on your droplet. If you are using key based authentication for SSH this will not change that but the password could be used in the console in the control panel in case of this type of problem. Since the console is considered by your droplet to be a local keyboard and display you can use your password there while only allowing key based authentication for ssh.
We have ran into the same issue today!
Can you please explain option 2? I don't know if I got it right but can we access our files with option 2? If that is possible then we can get the ssh or generate a new one?
Another question is that if we go with option 1, you have mentioned that "with all your files and configuration in place (but a new IP address)". Will that also include my nginx settings, php.ini, mysql (with the databases that was created!), etc?
Please advice.
What Ryan said! Especially the re-deployed snapshot fix.
We've been working on solving the remote key update/rotation issue at Userify. You could actually use it to solve your problem now in the same way that Ryan described (redeploying a snapshot) and just pass in the userify installer as a userdata script (using the CloudInit option in the Userify control panel), and then you can remotely update your authorized_keys file without droplet downtime.
