VPS login and password not accepted. Reboot in Rescue Mode results in root and temp password not being accepted

Bare Metal and VPS
1

Hi everyone,

I’m looking for a workaround for a persistent issue with OVH Rescue Mode. Despite following the official documentation, my VPS will not accept the root user and the temporary password generated by the manager after a reboot into Rescue Mode.

The Issue:

  • VPS rebooted into Rescue Mode.

  • Received the temporary password via email/dashboard.

  • Login attempts (via SSH and KVM/Console) fail with "Permission denied" or "Incorrect login."

  • Confirmed keyboard layout (AZERTY vs. QWERTY) is not the issue.

What we’ve tried:

  • Hired an external engineer who confirmed the credentials fail.

  • Contacted Support multiple times; received canned responses to "follow the instructions" despite sending screenshots of the failure.

  • We eventually had to migrate to a different provider just to get back online, but I still have two inaccessible VPS instances at OVH that I need to recover.

Has anyone found an "undocumented" trick to get these credentials recognized? Is there a specific SSH flag or a delay required before the password becomes active? It feels like a bug in the automated provisioning of the rescue environment.

Any advice would be greatly appreciated.

2

Please do :

ssh -v <ip_of_vps>

You will get a trace of the initial handshake, where both parts must agree on a common crypto algorithm.

If your PC is very old, try with a more recent computer on your side.

3

Hi Jon,

That definitely sounds frustrating, and you’re not the only one who’s run into this with OVH Rescue Mode. In similar cases, the issue wasn’t SSH flags or delays, but a broken rescue environment where the password never properly syncs. A workaround that sometimes helps is booting into rescue, mounting the VPS disk manually, and resetting the root password from a clean environment using a VPS recovery guide rather than relying on the automated credentials.

If console login also fails, that usually points to a provisioning bug on OVH’s side rather than anything you’re doing wrong. At that point, manual disk access or provider-side intervention is often the only reliable path to recovery.

Hope this helps, and good luck recovering those instances.