2017-01-18 3 views
0

J'ai une instance existante AWS Ubuntu EC2 (instance_1) avec accès distant ssh via une adresse IP publique, en utilisant mes propres clés privées/publiques. Je crée une AMI à partir de cette instance à l'aide de la console, puis lance une nouvelle instance EC2 (instance_2) à l'aide de cette AMI. ssh distant à instance_2 (via sa propre adresse IP publique) puis fonctionne exactement comme instance_1.L'authentification ssh échoue à aws ec2 instance lancée depuis ami créé avec boto3

Ensuite, j'utilise boto3 pour créer une AMI au lieu de la console, puis lancer une autre instance EC2 (instance_3). L'authentification ssh échoue (Autorisation refusée) sur instance_3.

Une idée de pourquoi le comportement est différent lorsque l'AMI est créée avec boto3 au lieu de la console? Les informations d'identification utilisées avec boto3 autorisent un accès administrateur complet à l'aide de la stratégie arn:aws:iam::aws:policy/AdministratorAccess.

Le code pour créer l'AMI:

ec2_client = boto3.client('ec2', region_name=region) 
response = ec2_client.create_image(InstanceId=instance_id, Name=ami_name) 
new_image_id = response['ImageId'] 
+0

Vérifiez la paire de clés associée. Vous pouvez vérifier la clé ssh de l'instance_3 en la détachant par exemple, puis monter le volume à partir d'une autre instance. Cela vous dira toute l'histoire. – mootmoot

+0

Merci @mootmoot C'était très utile pour trouver mon problème. Il s'avère que je passais le mauvais 'instance_id' à boto3! S'il vous plaît poster votre commentaire comme une réponse afin que je puisse l'accepter. – JCvdW

Répondre

0

Pour diagnostiquer le problème, vérifiez d'abord la paire de clés de l'instance EC2 vous tentez de vous connecter.

Si tout échoue (ce qui est rare), vous pouvez détacher l'instance et la transformer en volume standard, puis la monter à partir d'une autre instance pour valider ou remplacer ~/.ssh/authorized_keys.