My team has an issue that, when we spin up a new lightsail instance, we are only allowed to apply a single SSH key pair to that instance.
Is there a way to add the key pairs from everyone on my team to some kind of group? And then apply that group to the lightsail instance?
We need everyone on the team to be able to have access to the instance and I cannot find a way to accomplish this. Any insight would be greatly appreciated!
First thing, Private key is not designed to be used by the whole team and its really very bad practice you should not do that and you should not share the EC2 key with everyone.
Is there a way to add the key pairs from everyone on my team to some
kind of group? And then apply that group to the lightsail instance?
You have two option.
Ask for the public key from each developer and your team member, add their keys in ~/.ssh/authorized_keys files. They will be able to ssh against their own key.
This approach will help you to remove user once he has done his job and rotating user keys will be a bit easy.
OpsWork for user and ssh management for EC2 machine or you can explore amazon-ec2-instance-connect-for-ssh
With above approach you will not need to do an ssh and add new team member manually you do this with AWS console. I will prefer this.
I haven't used Lightsail before, but since it's uses EC2 under the hood I am assuming it's pretty much the same.
You can ssh into the machine with they private key provided by lightsail, and then you can add the public keys of the members of your team separated by a new line in this file
~/.ssh/authorized_keys
Then, the people from your team would use something like
ssh ec2-user#public-ip -i /path/to/private/key
If you used an Amazon Linux instance, user is ec2-user, but you used a different instance, the user is different.
If you want to add keys to multiple lightsail instances, I suggest to use a CM tool, like Ansible.
Related
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.
We know that a key pair must exist in order to access an EC2 instance.
I have created a key pair when I created EC2, but I saw the phrase that I could use an existing key pair.
Does this mean that if you are using an existing key pair, you can access multiple instances with one key pair?
Firstly, please note that keypairs are an industry standard for accessing Linux systems. Amazon EC2 supports their use, but the concept of keypairs was not created by AWS. Therefore, any method of using keypairs with Linux systems in general will also apply to Amazon EC2 Linux instances.
When you ssh into a Linux instance, you supply a username and the private half of a keypair. The Linux system will look in the nominated user's .ssh/authorized_keypairs file and will attempt to find the matching public half of the keypair. If found, it will allow you to start the ssh session.
Therefore, any keypair can be added to a user's .ssh/authorized_keys file. It can include multiple keypairs, all of which would be permitted to login as that user.
As a convenience, Amazon EC2 allows you to create or upload keypairs to AWS. They will appear in the Key Pairs section of the console. Then, when launching a new Amazon EC2 instance, you can nominate one of those keypairs. Software installed on the EC2 instance will copy the public half of the keypair to the /home/ec2-user/.ssh/authorized_keys file.
Bottom line: You can use the same keypair on multiple instances and you can also use multiple keypairs on the same user on an instance.
Yes, you can use one key pair for multiple EC2 instances. Click the "Launch" button and click "Choose an existing key pair."
I might have done something extremely stupid. I don't really know what I'm doing with this but have been following online guides to set up an EC2 Instance running Bitnami Wordpress.
Today I attempted to follow this guide to link Vaultpress to my instance:
https://www.virtualizationhowto.com/2016/04/connect-vaultpress-aws-ec2-instance/
I think I may have misstepped and pasted the public key text in the .ssh/authorized_keys inside the root user, overwriting whatever was there, (if there is information there by default?). I think, however, I was under a new user I created earlier, named vaultpress.
It is also possible that when I tried to add security groups I overwrote something something important. I have now reset the default VPC group and Security group generated by AWS Marketplace to 0.0.0.0/0 for SSH, so if I understand correctly that should be OK now?
Either way, I can now no longer SSH in with my .pem file. I did CHMOD 600 to the .pem file and used the standard ssh -i "thefile.pem" bitnami#address.com. Not sure where to go from here. Are there other ways to access the instance?
I get permission denied (public key)
ANY HELP REALLY APPRECIATED!
I thought I was going to make big track on my project with my day off today. Guess it's one step forward and two back today.
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.
A new developer joined our team and I need to grant him access to all VMs we have in AWS EC2. After reading a bunch of AWS docs it seems to me that we have two options:
Share the private key used when VMs were spun up with the developer
Have developer generate a new key pair and add his public key to authorized_keys on each VM.
Neither of options is ideal, because #1 violates security practices and #2 requires me to go to make changes to a bunch of VMs.
What's the recommended way to do this?
The question is rather broad, so my answer will be broad.
Yeah, sharing private keys is a bad thing. So I'll skip that and focus on the other portion.
It sounds like you want to centrally manage accounts, rather than manually adding/removing/modifying them on each individual server.
You can set up something like NIS to manage user accounts. This would require changes to every single VM.
If you use something like puppet, chef, or salt you can create recipes to control user access (e.g. pushing out public keys or even creating accounts and configuring sudo).
You can use something like pssh (parallel ssh) to execute commands on multiple hosts at the same time. It could simply add a public key to an existing authorized_keys file or even add a user, its key, and necessary sudo access. (Note: if you do this be very careful. A poorly written command could cut off access for everyone and cause unnecessary down time).
An aside: Having multiple users share a single account is a bad idea, generally a security and QA nightmare. Instead of allowing multiple access to the same account each user should have their own account with the minimal privileged access they need.
Do as you will.
Have you checked out the feature Run Command to execute a simple script to add or remove users.