I have an application that runs on AWS BeanStalk and one requirement is to connect to another server using ssh. I could log as root into the server and generate a key pair that i can use but this would not scale. (we have auto-scaling enabled)
Is there a way to generate and replicate a key pair across the instances that are running?
Edit - I feel the need to provide a better description to my problem.
When I lunch the BeanStalk instance i selected the previously created keypair but looking at the EC2 documentation here it states the following:
Amazon EC2 stores the public key only, and you store the private key.
This seems to work ok as I am able to ssh into the ec2 instance. We have another service that is running on a DigitalOcean hosted machine, and we need to ssh from the ec2 instance to the digitalocean instance.
Important The DigitalOcean instance can only allow key based authentication (user/password authentication is not allowed)
When i log into the ec2 machine i can see that in the .sshfolder i only have the authorized_keys file and that would make sense taking into consideration the documentation paragraph.
Is there a way to get a public key that i could use to log into the digitalocean instance from the ec2 instance?
If I understand you correctly, you need the Beanstalk application to SSH in to another server?
Every EC2 instance gets launched with a designated keypair. You have the option of either creating a new keypair or using a keypair already set (i.e. the keypair created by the Beanstalk application for the first instance).
Keeping the private key on the Beanstalk instance, launching the other instance(s) using that same keypair would allow the application to use the private key to SSH in and also allow you to scale the instances without your having to go in to each one and create new keypairs.
That said, I believe the documentation suggests against keeping the private key on the instance, so perhaps consider launching the non-Beanstalk instances with a configuration script that creates a customized user, perhaps using a key and password and pre-configuring the application with that information? You can keep that information as environment variables within Beanstalk itself, similar to how you would keep RDS credentials.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html
When you launch an instance in Amazon EC2, you have the option of
passing user data to the instance that can be used to perform common
automated configuration tasks and even run scripts after the instance
starts. You can pass two types of user data to Amazon EC2: shell
scripts and cloud-init directives. You can also pass this data into
the launch wizard as plain text, as a file (this is useful for
launching instances via the command line tools), or as base64-encoded
text (for API calls).
EDIT 1
In order to SSH from computer A to computer B, computer A needs to have the private key in the .ssh directory and computer B needs to have the public key appended to the authorized_keys file in the .ssh directory, so that's perhaps why you don't see either key in the Elastic Beanstalk EC2 instance.
Since you have the public key within the authorized_keys file, you can simply replicate it to the DigitalOcean instance (once it's on the server, do cat public_key >> authorized_hosts) and since you're able to SSH in to the Elastic Beanstalk instance, you can simply take the private key from your computer and put it in the .ssh directory of the Beanstalk instance. That way, now the DigitalOcean instance will have just the public key appended to the authorized_keys file and the beanstalk instance will now have both the private key and public key as authorized to login.
That said, this is probably the most insecure way of doing this...I would prefer you generate a new key and use that to be able to SSH from the Beanstalk instance to the DigitalOcean instance.
Note, this is not the same as creating a new IAM user, though you can use IAM to simply create new key pairs.
EDIT 2
I guess it will be difficult for an EC2 instance to automatically obtain the private key upon being automatically launched, so the way I see it, you have three options;
1) EC2 instances can be (auto)launched with a custom "user data" script, which I referenced above. In that script, you can include the actual private key data (pretty bad idea IMO) OR have it obtain the private key from somewhere (e.g. SCP with username/password into some machine and download it). Again, all pretty bad ideas.
2) Embed the private key within your Beanstalk application. Not knowing what language your application is written in, it's difficult to determine how bad / good of an idea this is. If it's in Java, private / sensitive keys get embedded all the time, so I don't see why this would be any different. This seems to me to be a fine idea, iff this is an application developed specifically for this use case and will never be used anywhere else. I'd hate to see a developer accidentally deploy this app somewhere else and now that private key is potentially compromised.
3) You could create an AMI of the EC2 instance with the key embedded in it. Then simply instruct the autoscaling to launch a new instance of that AMI and voila, you will have the key in the .ssh directory. I tend to like this idea the best as it uses AWS resources for what they're intended, and I would think makes the key a bit more 'secure' (outside of compromising the EC2 instance itself, it will be much more difficult for anyone to access the key). This wouldn't add any additional scalability over option #2 as you can scale / deploy a Beanstalk application just as much as you can an AMI image. That preference is up to you.
NOTE, this of course says nothing about scaling the DO machine, assuming that's even a requirement.
Related
Yesterday I downloaded Filezilla, after the downloading, I got warn message from my computer, and when I checked the download folder, all data were deleted including putty key and .PPM file. could anyone explain me please, how can I recover these files?
Once you download an AWS pem you can never redownload it again (this is for security purposes if your account was compromised).
Best practice would be store anything of value in an external storage, rather than on a single users machine.
Unfortunately as it stands the instances will not be connectable over SSH without having a PEM. This isn't to say you have lost access to these instances however.
If the individual host is not of importance or can be recreated very easily, you could simply create a new SSH key within AWS and launch new instances using this configuration. You can always create an AMI of the current instances to launch ew one that is identical but specify your new SSH key when you launch.
If the hosts are important AWS support to allow you access the host via a terminal. Before accessing generate a new private/public key and then add the public key to the hosts .ssh/authorized_keys file once you have gained access.
The simplest solution would be to use Sessions Manager to allow you to access the host either via the console or the CLI.
For sessions manager the instances IAM role will need to grant permissions as well as the agent being previously installed.
Bear with me, what I am requesting may be impossible. I am a AWS noob.
So I am going to describe to you the situation I am in...
I am doing a freelance gig and was essentially handed the keys to AWS. That is, I was handed the root user login credentials for the AWS account that powers this website.
Now there are 3 EC2 instances. One of the instances is a linux box that, from what I am being told, is running a Django Python backend.
My new "service" if you will must exist within this instance.
How do I introduce new source code into this instance? Is there a way to pull down the existing source code that lives within it?
I am not be helped by any existing/previous developers so I am kind of just handed the AWS credentials and have no idea where to start.
Is this even possible. That is, is it possible to pull the source code from an EC2 instance and/or modify the code? How do I do this?
EC2 instances are just virtual machines. So you can use SSH/SCP/SFTP files to and from. You can use the AWS CLI tools to copy stuff from S3. Dealers choice...
Now to get into this instance... If you look in the web console you can find its IP(s), what the security groups (firewall rules), and the key pair name. Hopefully they gave you the keys. You need these to SSH in.
You'll also want to check to make sure there's a security group applied that has SSH open. Hopefully only to your IP :)
If you don't have the keys you'll have to create an AMI image of the instance so you can create a new one with a key pair you do have.
Amazon has a set of tools for you in Amazon CodeSuite.
The tool used for "deploying" the code is Amazon CodeDeploy. By using this service you install an agent onto your host, then when triggered it will pull down an artifact of a code base and install it matching hosts. You can even specify additional commands through the hook system.
But you also want to trigger this to happen, maybe even automatically? CodeDeploy can be orchestrated using the CodePipeline tool.
I'm 100% new to AWS and I'm working on deploying my personal site. I've spun up an EB environment via the AWS EB CLI and but I would also like to be able to SSH into the EC2 instance that gets created however I can't locate the private key (.pem) file that is associated with it which I need to chmod for permit SSH'ing in.
Does a private key file get created when you create an EC2 instance via Elastic Beanstalk? If so where can I find it? Thanks a ton.
It is so valuable question for the AWS beginners.
I was also confused with this question but get clear after a while.
I know you used the EB CLI for handling the EB.
With the EB CLI you don't need the .pem file for normal use.
Because the EB CLI has 'eb ssh' for connecting the EC2 instance of your EB.
Please check out : https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb3-ssh.html
Also you can't get the standard .pem file of your EB.
There are some steps.
Please check out : SSH to Elastic Beanstalk instance
Elastic beanstalk still provisions EC2 instances and an SSH key can be assign to them.
You have two options if you didn't attach a key to an instance at provision time or have since lost it.
Provision a new instances with a key attached to it.
Snapshot the instance, Provision a new instances with a key attached and references the snapshot id of the old instance.
One should be easier with Elastic Beanstalk, just provision a new environment with keys attached to the instance, you will lose data with this method though.
More in depth steps for #2 can be found here
. This will help you retain data if need be.
eb ssh only works if you have the keys and have attached them to the instance. Private key files must be located in a folder named .ssh under your user directory
eb init will ask if you want to ssh into your instance, then list out the keys in your account in that region. If a new key was created it should have outputted where the key was place on your filesystem.
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb3-init.html
eb create has a -k key option as well
If you include this option with the eb create command, the value you provide overwrites any key name that you might have specified with eb init.
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/eb3-create.html
I'm essentially an AWS noob.
I had a developer set up an EC2 instance with load balancer to host a node.js-based API. He has now moved on from the company but he still have the private key to log in, if he wanted to. I want to change the keys.
From what I have read, I need to relaunch the instance to get a new key pair. However, if I do this will I lose all the node packages, and other SW that has been installed on the current instance? What will happen with the load balancer? Do I need to need to update my DNS info to point to the new IP?
(Once situated, this time around I will create multiple key pairs for the devs to use.)
Thanks,
Steve
EDIT: Yes, I do have the private key and can do everything I need to. I just want to make sure HE no longer has access.
Take a an AMI of the current instance for backup purposes. This will reboot the instance but it will keep the existing IP. You do not need to remove it from your ELB. You may need this AMI if you you cannot connect back in after changing the key.
Login as the root user, with the existing key.
From the shell, run the following commands:
$ ssh-keygen -t rsa -b 2048 -f user - this generates a new key pair
$ sudo su - - if needed
$ cp /home/ubuntu/.ssh/authorized_keys /home/ubuntu/.ssh/authorized_keys.bak - backup the existing public key
$ mv user.pub /home/ubuntu/.ssh/authorized_keys - this replaces the existing public key in the authorized_keys file
$ chmod 600 /home/ubuntu/.ssh/authorized_keys - Change permissions on the file
Copy the private key (file called user) generated from the $ ssh-keygen command to your local machine and delete it from the instance.
Connect to the instance with the new private key to confirm. IMPORTANT: Keep the existing ssh session open and create a new session with the new key.
If you have any problems on step 10 you still have access to the existing session to troubleshoot.
As for cleanup make sure and remove the old key pair from the AWS console, and invalidate any credentials IF(!) they are not required for the existing services to run. If you granted the developer root access to your AWS console, you should reset those credentials.
NOTE: These steps assume an Ubuntu installation. If you are using any other Linux type, replace \ubuntu with the correct AWS username:
Amazon Linux: ec2-user
Ubuntu ubuntu
Debian admin
RHEL 6.4 ec2-user
RHEL 6.3 root
You can create a new Key Pair without creating a new EC2 instance http://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-key-pairs.html#having-ec2-create-your-key-pair
It still looks like you need to launch a new instance of EC2 (which creates a new key), but if you use the same volume(s) or snapshots to create duplicate volumes you shouldn't have to reload any Software.
https://forums.aws.amazon.com/message.jspa?messageID=245314
As for DNS, I would point it to the load balancer, that way you can add/remove servers from the pool without DNS changes. Otherwise, assign an Elastic IP to the server, that way you can move the Elastic IP to the next server without changing DNS each time. Moving Elastic is instant, where DNS takes time to replicate to rough the network. Hope that helps.
So, I have resolved this issue myself, and I'm posting what I did in case it helps anyone else.
On my local machine I made a new 2048 bit RSA key pair (a new pair can also be generated on AWS)
Import the new public key in the Amazon console.
Create an AMI of the running instance.
Launch an new (ubuntu linux) instance of that AMI, and point it to
the newly uploaded public key for login.
Once the instance is up, update Load Balancer, or DNS entries
to point to the new instance, as appropriate.
Start whatever software the server is intended to run.
I need to share an ami so that it can be used by a client to create their own instances through their own account. However, I do not wish that client to be able to ssh in to the instance. I will need to be able to ssh into the instance to be able to maintain it. They will have ftp and www access only. I've got the ftp and www access part working through ssh configuration. How do I keep them out of ssh when they are starting up the instance with their own keypairs?
Well, you can't really prevent this, if they are determined to get in, since they control the instance.
Stop instance → unmount root EBS volume → mount elsewhere → modify contents → unmount → remount → restart → pwn3d.
However, according to the documentation, if you don't configure the AMI to load their public key, it just sits there and doesn't actually work for them.
Amazon EC2 allows users to specify a public-private key pair name when launching an instance. When a valid key pair name is provided to the RunInstances API call (or through the command line API tools), the public key (the portion of the key pair that Amazon EC2 retains on the server after a call to CreateKeyPair or ImportKeyPair) is made available to the instance through an HTTP query against the instance metadata.
To log in through SSH, your AMI must retrieve the key value at boot and append it to /root/.ssh/authorized_keys (or the equivalent for any other user account on the AMI). Users can launch instances of your AMI with a key pair and log in without requiring a root password.
If you don't fetch the key and append it, as described, it doesn't appear that their key, just by virtue of being "assigned" to the instance, will actually give them any access to the instance.
I was able to finally accomplish this crazy task by using this process:
1) Login as ubuntu
2) create a user, belongs to sudo and admin group
3) install all my s/w under the newuser
4) verify that new user has all required privileges
5) chroot jail the ubuntu user to ftp access only
when the ami is transmitted to the new zone/account, the ubuntu user exists as a sudoer, but cannot ssh into the instance. Ftp allows them to connect to the system, but they view a bare directory and cannot cd anywhere else in the system.
It's not a complete denial, but I think it will serve the purpose for this client.