I am trying to initiate an instance that is found here...
https://aws.amazon.com/amis/aws-tools
The instance is launched but when I try to login, I get the following message:
ssh -i oct9.pem root#ec2-50-16-125-42.compute-1.amazonaws.com
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
If I launch a new instance using the built-in wizard, It works as expected with the same .pem key.
This AMI was working as expected till recently. I have used it before for a few instances. I would like to use this because it has several utilities pre-installed.
When you produce a new image from a running instance, you end up getting locked out of the running instance. I'm not sure why, but you can then re-launch a new instance from the image you just created.
It's unclear whether or not this is the issue you're running into, though.
Related
I have an ec2 micro instance. I can start it from the console, ssh into it (using a .pem file) and visit the website it hosts.
Using the old ec2 CLI, I can start the instance and perform other actions including ssh and website access.
I am having trouble with the new ec2 CLI. When I do "aws ec2 start-instances --instance-ids i-xxx" I get the message "A client error (InvalidInstanceID.NotFound) occurred when calling the StartInstances operation: The instance ID 'i-xxx' does not exist".
Clearly the instance exists, so I don't what the message is really indicating.
Here is some of my thinking:
One difference between the old and new CLI is that the the later used .pem files whereas the new interface uses access key pairs. The instance has an access key pair associated with is, but have tried all the credentials I can find, and none of them change anything).
I tried created an IAM user and a new access key pair for it. The behavior in all cases is unchanged (start from console or old CLI, web access, ssh) but not using the new CLI.
I realize that there is a means for updating the access key pairs by detaching the volume (as described here), but the process looks a little scary to me.
I realize that I can clone another instance from the image, but the image is a little out of date, and I don't want to lose my changes.
Can anyone suggest what the message really means and what I can do to get around the problem?
The problem had to do with credentials. I had the correct environment
variables (AWS_ACCESS_KEY and AWS_SECRET_KEY) set. But they didn't match what was in my .aws/credentials file. That is, despite what it says here, the new CLI worked only when I had the environment variables and
the credentials file correct and in sync.
Configure your aws cli with "aws configure" in new cli instance with region in which your ec2 instance reside. and then try to give the same command. The instance should start.
I have created a EC2 Instance using the cloud formation script and in that process I have executed around 20 commands in "AWS::CloudFormation::Init". This is a windows instance.
After that, I created a image from this and tried to create another EC2 instance using this image with couple of commands I wanted to be executed in "AWS::CloudFormation::Init".
This is giving me problem. The instance after getting created is not running the new commands which I specified in the template. But trying to run the commands which I specified while creating the old EC2Instance from which image was taken. This is through sysprep process which was given in one of the docs.
Is there any way to execute only the new commands and leaving out the old commands when the new image is created. I tried many alternatives. It is either executing old commands or none at all.
Have you stopped your instance before creating your image ? (like advised here).
i am facing some problem with userdata execution on windows AMI, trying to execute the userdata like, opening notepad start notepad.exe i had tried to execute this its not working,this script is getting copied to instance but when i tried to connect to instance the notepad didn't open..Any one had faced the similar problem?
Userdata is only used when an instance is launched for the first time. It can be used to configure or run process on your instances when you first launch it. This is useful if you have a lot of instances you need to setup at once.
Userdata scripts do not run when you connect, but you could use it to add scripts to windows startup.
I am windows user and wanted to use a spot instance using my own EBS windows AMI. For this I have followed these steps:
I had my own on-demand instance with specific settings
Using AWS console I used option "Create Image EBS" to create EBS based windows AMI. IT worked and AMI created successfully
Then using this new AMI I launched a spot medium instance that was created well and now running with status checks passed.
After waiting an hour or more I am trying to connect it using windows 7 RDC client but is not reachable with client tool's standard error that either computer is not reachable or not powered on.
I have tried to achieve this goal and created/ deleted many volums, instances, snapshots everything but still unsuccessful. Doesn't anybody else have any solution to this problem?
Thanks
Basically what's happening is that the existing administrator password (and other user authentication information) for Windows is only valid in the original instance, and can't be used on the new "hardware" that you're launching the AMI on (even though it's all virtualized).
This is why RDP connections will fail to newly launched instances, as will any attempts to retrieve the administrator password. Unfortunately you have no choice but to shut down the new instances you've been trying to connect to because you won't be able to do anything with them.
For various reasons the Windows administrator password cannot be preserved when running a snapshot of the operating system on different hardware (even virtualized hardware) - this is a big part of the reason why technologies like Active Directory exist, so that user authentication information is portable between machines and networks.
It sounds like you did all the steps necessary to get this working except for one - you never took any steps to cause a new password to be assigned to your newly-launched instances based on the original AMI you created.
To fix this, BEFORE turning your instance into a custom AMI that can be used to launch new instances, you need to (in the original instance) run the Ec2ConfigService Settings tool (found in the start menu when remoted into the original instance using RDP), and enable the option to generate a new password on next reboot. Save this setting change.
Then when you do create an AMI from the original instance, and use that AMI to launch new instances, they will each boot up to your custom Windows image but will choose their own random administrator password.
At this point you can go to your ec2 dashboard and retrieve the newly-generated password for the new instance based on the old AMI, and you'll also be able to download the RDP file used to connect to it.
One additional note is that Amazon warns that it can take upwards of 30 minutes for the retrieval of an administrator password after launching a new instance, however in my previous experience I've never had to wait more than a few minutes to be able to get it.
Your problem is most likely that the security group you used to launch the AMI does not have RDP (TCP port #3389) enabled.
When you launch the windows AMI for the first time, AWS will populate the quicklaunch with this port enabled. However, when you launch the subsequent AMI, you will have to ensure that this port is open for your security group.
I use libcloud to create a new node instance Amazon EC2.
conn.create_node returns me a valid instance and printing node.dict shows the expected values.
however when I check my EC2 dashboard the new machine does not appear there.
do I need my python app to stay open so that the node is actually created?
found it: the instance was actually created but for some reason the amazon did not show it even after refresh. logging out and in solved it.