Here's my issue
I have an ec-2 instance on AWS running Ubuntu Server. During the initial launch of the instance, I generated the key-pair by going to AWS console --> Key Pairs --> Create key pair. It generated a key abcxxxx.pem and I have saved it.
Here's where the issue starts
I head a project where multiple developers come on and off. Without
too much thought, I distributed my .pem file to 2-3 developers. They
have left the project since and I want to restrict AWS access to only active
developers. Basically I don't want the 2-3 developers (with .pem file) to access my machine.
For all the new developers ( I no longer distribute .pem file), I give access to AWS machine by pasting
there public key in /home/ubuntu/.ssh/authorized_keys. This
gives them access to the machine.
My two questions are as follows
How can I restrict access to people who already have .pem file?
Will deleting their public key from /home/ubuntu/.ssh/authorized_keys make a difference? NOTE: I still have the key and only I have the access to AWS console.
How are the new developers able to access the AWS machine without a .pem file? (The only thing I do is paste their public key in the authorized_keys on AWS)
How do I implement a system where I have sole access and I deal with developers coming on/off on the project?
All users(including me) who's public key is in the authorized_keys on AWS machine can login without a .pem file. How is this possible? Doesn't everyone need a .pem file to ssh in?
I'm really confused about this key-pair business (what's the role of .pem file?) and other posts online don't seem to help (even AWS support). Most posts online address scenarios where you lose the key and you have launch a new instance etc. etc. I contacted AWS support and they just sent me this link. I don't understand how this helps.
Any solution/elaborate answer will be really helpful.
For the most part, your question is really about how to administrate users and SSH on Ubuntu. The keypair that you generated using the console is only used when the instance first launches. It is always available via instance metadata; you can see that by running the following command from the shell on the EC2 instance:
$ curl http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key
which outputs:
ssh-rsa ...blah blah blah...
When your EC2 instance first launched, this key was copied into /home/ubuntu/.ssh/authorized_keys because the Ubuntu AMI you're using is set up to do that. But that's just a convention. That's the only time that the key will get automatically copied anywhere, so from there on out you can manage the authorized_keys file however you like.
Regarding your specific questions,
If the original public key you created on the console is still in authorized_keys, then anyone who has the corresponding PEM file can still log in. To correct this, you would need to carefully remove that key from the authorized_keys file (for example, first making absolutely sure that you can log in with a different key).
While they may not have the PEM file you downloaded from the AWS Console, they must somehow have gotten the PEM file (or some rough equivalent) for one of the public keys that you added to authorized_keys.
There are lots of different ways. As mentioned above, it's more of a matter of how you want to administrate users under Ubuntu. Since you seem to want to retain control over the machine, you could create user accounts for each of the developers to log into, and then give them limited rights to use sudo in certain cases (assuming they need that at all). You could then revoke these accounts whenever you wanted.
My understanding is that there are just many different ways to provide the equivalent of a PEM file to ssh, and somehow you (and your developers) must be doing that. I'd recommend perusing the ssh documentation.
I hope this helps!
Taking a stab at this:
1) You cannot remove the key from authorized_keys without losing access yourself to the server. The public key in there proves to the server that you are who you say you are when you auth to the server via SSH using the pem.
2) For the new developers, they do pass in a key when the ssh to the machine. It's just their key and it's implicitely passed in, vs the key you've used to spin up the machine. The presence of their public key in the authorized_keys signals to the server that they are authorized to access the machine once their ssh client proves it has the private key that matches the public key in the authorized file.
3) i would just create additional users on the box and set them up for passwordless login by setting up /home/newusername/.ssh/authorized_keys pretty much the same way you set it up for the ubuntu user today. when they leave the project just disable and/or delete the accounts
4) It's possible to login without specifing a pem, but you still specify a key. To see the key exchange and how the auth takes place do "ssh -vvv user#machinename" and you will see the whole ssh dialogue. When you don't specify a key, the ssh client will look for one in a couple of predefined locations. you will see the client attempt to use each of these keys (you're probably picking something up from ~/.ssh/id_*). A pem is not a magic file. It just keys (it may contain a public key, a public and a private key or a public key and the whole cert chain).
I would recommend you read on public/private key crypto to understand how it works.
https://en.wikipedia.org/wiki/Public-key_cryptography
https://www.youtube.com/watch?v=svRWcx7dT8g
https://staff.washington.edu/dittrich/misc/ssh/
Related
From what I read, ~/.ssh/authorized_keys just take what is in the project level metadata. If i delete an entry from the console, it disappears from the authorized_keys file too.
However, if i delete from the authorized_keys file, the console still shows the entry with the deleted public key.
Once I exit the ssh session, I'm then not able to go back in with either gcloud compute ssh user#instance_name or ssh user#instance_ip. Why is this so?
I had to then go to the console and delete that entry (that i previously removed by editting authorized_keys file directly) and only now gcloud compute ssh user#instance_name works properly again, helping me add my google_compute_engine.pub into project metadata so ssh user#instance_ip now works too.
P.S I'm unfamiliar with how instance level metadata works so only experimented with project level metadata ssh keys. If any answer can comment whether your answer applies to instance level too that'll be great.
One can provide SSH keys either on the project or instance level. Please don't edit files, but add them on the GCE console, becaause they're generally managed by GCP. So that one can even eg. generate and provision a new key, run a script, let the key expire. Alike this one does not have to store the key anywhere ...which is quite unlike a traditional VM. The amount of keys one can add into instance meta-data is limited.
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.
Currently, I am facing an issue related to AWS. A project is already uploaded on AWS server and always connect to that Project by using PEM key of that particular project. But from last week I am not able to connect with the AWS server by using the PEM key. I got one solution for this, as by creating new instance i will be able to got my access on the project but this will make me lose of my whole data & database as a result. Is this occurred due to virus or any thing else? Got stuck over here badly. Any help will be appreciable.
I think the authorized_keys file has some incorrect entries. Let's remove the key from the file and add it again.
remove the host key
ssh-keygen -R [hostname]
ssh again
ssh -Tv ec2-user#example.com -i ~/mykey.pem
In order to use existing EBS volume with data in a new ec2, with a new ssh key:
Create a snapshot of the current instance's EBS, and create a volume.
Create a new instance with a new ssh key.
Stop the new instance and attached the previously created volume as the boot volume.
Start the new instance and you should be able to login with the new ssh key.
The log indicates that you do not have any networking issues. It is the ssh server on the instance that is rejecting your connection.
The first thing to confirm is that you are connecting to the correct Amazon EC2 instance. If an EC2 instance is stopped and started again, it might change public IP address (depending how it is configured). Therefore, make sure that you are connecting to the right instance.
Next, confirm that you are using the correct username. You are using ubuntu#, which is correct if the instance is using an Ubuntu AMI. However, it is possible to create additional users on a Linux computer and the PEM files are associated with specific users. Therefore, confirm that this is the correct username for use with that PEM file.
Next, confirm that you are using the correct PEM file. The PEM file should contain the private half of a keypair that matches the public half that is stored on the instance in the user's ~.ssh/authorized_keys file. The log indicates that the instance is rejecting the provided keypair. Therefore, you might be using the wrong one.
Failing all this, there are some recommended steps available on: Walkthrough: Reset Passwords and SSH Keys on Amazon EC2 Instances - AWS Systems Manager
However, they might not work since you are using an Ubuntu instance, which might not have standard AWS software installed.
Let us know how you go!
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.