Bonjour,
je viens poser une question car il y a quelque chose que je ne comprends pas dans le fonctionnement du "rescue mode". Je dois changer ma clé SSH sur mon serveur (instance). Pour cela, je le lance en rescue mode "https://docs.ovh.com/fr/public-cloud/passer-une-instance-en-mode-rescue/" (pas de souci) et ensuite je vois bien le mot de passe "root" dans la console VNC et j'arrive à m'y connecter. Par contre pas moyen de faire de copy/past pour ma nouvelle clé SSH.
Mais lorsque j'essaie de me connecter en SSH depuis chez moi (j'ai essayé via un autre réseau également), je reçois le time out
Or pour copier/coller ma nouvelle clé SSH je dois passer par cette connexion. Avez-vous une idée de pourquoi je ne sais pas établir une connexion ? J'ai essayé avec 3 plateformes différentes (VPS OVH, Windows 10 (putty) et Fedora (Terminal ssh).
Merci d'avance pour votre retour,
SOLVED Mode rescue pour changer SSH Key (pas de connexion SSH)
Sujets apparentés
- [RESOLU] Connexion impossible en SSH
14082
05.06.2019 20:05
- Bonjour, Je n'est reçus aucun mot de passe root lors de mon achat!
10218
05.02.2018 20:47
- Configuration IP failover avec netplan (Ubuntu 17.10)
8408
12.01.2018 23:23
- IP Failover sur Debian 9
6656
18.11.2016 20:40
- Ssh connection timed out port 22
5689
11.12.2019 08:21
- Problème connexion ssh
5392
04.02.2018 09:46
- Connexion OpenStack Swift Object Storage
5115
11.04.2019 10:09
- Désactivation de mon site pour Phishing
4835
12.05.2021 08:36
- [RESOLU] VNC Console - Coller un texte
4093
14.01.2018 18:48
- [Officiel] Roadmap Public Cloud
4010
02.06.2017 08:53
Dans ton VNC, je vois le mode 'rescue' et non ton serveur...
En rescue, tu dois monter ton disque par exemple dans /mnt
puis cd /mnt/root/.ssh
et là tu mets ta clé dans authorized_keys2
et puis cd / & umount /mnt & reboot
Oui en mode rescue j'arrive bien à monter le disque ==>

Mais je ne sais pas faire de copy/past en utilisant VI ou VIM dans la console. Si j'essaie de me connecter avec les mêmes infos depuis un PC sous FEDORA via le terminal en SSH je reçois un "time out". Depuis un terminal je peux faire du Copy/Past sans souci. Maintenant si il y a moyen de faire du Copy/past dans la console VNC de chez OVH je suis preneur ;-)
Merci
cat >> authorized_keys2
et puis (paste)
et puis ^D
Merci pour ton retour.

Oui je sais faire du Copy/Past dans un terminal ;-) mais la connexion dans un terminal ne fonctionne pas. Donc je suis dans la console VNC OVH et pas moyen de faire du copy/paste :-( ==>
Est-ce que mon explication est plus claire ?
merci :-)
Si tu es en console kvm tu dois pouvoir faire un wget non ?
Essaie de publier ta clé publique sur un accès web, puis tu fais un wget url pour récupérer la clé... ça évite le soucis du copier / coller.
Salut @ExternalizI
A la base de tout ça, un truc m'intrigue tout de même.
Tu indique ne pas parvenir a te connecter en SSH au mode rescue !
Ca peut venir de plusieurs chose.
La plus courante viens du vRack ! Est-ce que tu as un interface privée sur l'instance ?
Si oui, est-ce que tu n'aurais pas simplement active la gateway sur ce réseau ??
explication :
openstack ne sais pas privilégier un réseau d'un autre. Du coup, si tu as set une GW dans ton vRack (inutile d'ailleurs si tu n'a pas un service qui joue ce role), je te recommande fortement de la désactiver !
Ceci fait, reboot simplement l'instance et tu pourras te connecter en SSH au rescue mode.
Quand tu es connecté a ta console VNC, un petit `route -n` pourra te le dire.
Pour modifier la route par defaut a chaud :
`# route add default gw `
Après, a toi de check si tu n'as pas mis un Firewall Network sur l'IP (coté OVH) ou un security group (coté Openstack).
Autre chose. La console VNC ne prends pas en compte les copy/paste... du coup, si vraiment tu n'as pas d'autre solution, il te faudras fonctionner autrement comme dit par Sich : mise a dispo de la clé publique dans un espace web t'appartenant, un petit wget ou curl sur le ficher et tu l'injecte dans ton fichier ssh.
Par contre, pour moi ici, le soucis premier est que tu ne parvienne pas a te co en ssh a ton instance en Rescue ! c'est vraiment là que tu dois creuser je pense.
Jalinn
Oui j'ai pensé pareil, parefeu ovh qui reste actif même si on est en rescue...
J'ai le soucis vu que je n'ai pas ssh sur le port 22, par conséquent je dois ouvrir le port ou couper le parefeu quand je passe en rescue...
Hello à vous,




merci pour vos interventions. Je vais essayer d'être clair :-) Avant de faire un WGET j'aimerais effectivement comprendre ce qu'il se passe. Merci à Sich pour le WGET et à Jalinn pour ses explications.
@Jalinn : Voici mon instance et les GW (j'ai mis des chiffres pour répérer les GW dans mes "printscreen".
quand je fais le route -n je vois bien ma GW
Et enfin j'ai bien un réseau privé (2°) ==>
@Jalinn : je ne comprends pas la route qu'il faut modifier pour faire du SSH vu que toutes les GW sont présentes quand je fais un route -n et pas de règles FW
Merci pour vos retours car je ne comprends pas où je dois continuer à chercher et/ou changer. :-)
Hello.
Le soucis, c'est en masquant l'ensemble des adresses ce n'est pas simple x)
dans ton route -n, regarde ta première ligne :
dest 0.0.0.0 Gw x.x.x.x [...] ens4 ==> tout le trafic qui doit partir vers l'exterieur (dest 0.0.0.0) part via ton port vRack (généralement ens4 = vrack, ens3 ext-net).
ex de conf bonne ou la GW ext-net est mise par defaut (sur une de mes instances) :
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 0.0.0.0 54.xx.xx.1 0.0.0.0 UG 0 0 0 eth0 <<<==== destination par defaut sur ext-net
> 10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1 <<<==== routage de mon interface vrack
> 54.xx.xx.1 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
> 169.254.169.254 10.0.0.3 255.255.255.255 UGH 0 0 0 eth1
Dans ton cas, je pense que tu dois avoir ça du coup :
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 0.0.0.0 10.xx.xx.1 0.0.0.0 UG 0 0 0 eth1 <<<=== destination par defaut sur vrack
> 54.xx.xx.1 0.0.0.0 255.255.255.0 U 0 0 0 eth0 <<<=== routage de mon interface vrack
Pour fix rapidement, tu peux redéfinir ta route par défaut via la console VNC :
> `# route add default gw 54.xx.xx.1`
et là, magie, ton IP ex-net va prendre le dessus et tu pourras te connecter.
Concernant l'adresse APIPA => elle est utilisée par le service metadata agent d'Openstack pour charger les info cloud-init (entre autre), lors du démarrage de la VM.
C'est tout a fait normal donc :)
Hello,


merci beaucoup pour vos interventions et désolé pour mon temps de réponse mais j'étais occupé sur d'autres soucis IT chez mes clients. J'ai bien réussi à faire ma connexion depuis le mode rescue mais je n'arrive pas à mettre ma nouvelle clé SSH elle ne s'enregistre jamais :-(
je liste le dossier ssh avant de monter mon disque ==>
Ensuite je monte le disque dans mnt et je reliste le dossier ssh ==>
j'ajoute ma nouvelle clé dans ce fichier authorized_keys2 et ensuite je fais un umount /mnt mais elle ne s'enregistre jamais. D'ailleurs si je liste les deux fichiers authorized_keys sur /root/.ssh et sur /mnt/root/.ssh ils ne sont pas identiques. J'ai loupé une étape ?
Merci pour votre retour