SOLVED Mode rescue pour changer SSH Key (pas de connexion 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

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

Depuis un terminal je peux faire du Copy/Past sans souci

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