2016-05-08 3 views
-1

J'essaye de cloner une instance EC2 pour pouvoir tester certaines choses. J'ai créé une AMI et lancé une instance qui semble fonctionner correctement. Cependant, je ne peux pas me connecter avec ssh ou putty.Connexion à une instance EC2 clonée

Mon instance live, dont je fais la copie, a plusieurs utilisateurs qui peuvent tous se connecter avec leur clé privée. Mais ils ne peuvent pas se connecter avec exactement les mêmes informations d'identification à l'instance clonée. Je viens d'obtenir:

Disconnected: méthodes d'authentification non pris en charge disponible (serveur envoyé: publickey)

est-il plus à faire que de simplement changer l'adresse IP de l'instance en direct à l'instance cloné?

Je ne peux pas non plus me connecter au login de l'utilisateur ec2, en utilisant la clé privée que j'ai créée lors du lancement. Une petite bizarrerie de mon serveur live est que j'ai dû changer le paramètre AuthorizedKeysFile dans/etc/ssh/sshd_config afin de résoudre certains problèmes SFTP que j'avais. Est-ce que cela a probablement gâché la connexion pour un serveur cloné? Sûrement tous les paramètres sont identiques?

+0

La nouvelle instance d'un groupe de sécurité dont le port 22 est ouvert? –

+0

Oui, j'utilise le même groupe de sécurité pour les deux instances. –

+0

Comment avez-vous 'clone' l'instance? En outre, lorsque vous dites "en utilisant la clé privée que j'ai créée lors du lancement", faites-vous référence au lancement de l'instance d'origine ou du clone? Avez-vous essayé d'utiliser la paire de clés qui fonctionne avec l'instance d'origine ET celle utilisée lors du lancement du clone? Que montre 'ssh -v'? –

Répondre

0

La réponse était à faire avec le paramètre AuthorizedKeysFile après tout. J'ai annulé l'édition que j'ai faite dans/etc/ssh/sshd_config, pris un autre instantané, fait une autre AMI, lancé une autre instance et tout allait bien. Je n'ai même pas besoin de redémarrer le service sshd, donc cela n'a pas gâché ma configuration sur mon serveur live. Je ne suis pas entièrement sûr pourquoi cela a causé un problème, mais la leçon ici est que EC2 a besoin de l'AuthorizedKeysFile à l'emplacement par défaut ou je suppose qu'il ne sait pas où chercher la clé publique.