I had setup amazon EC2 instance on AWS. I can access the instance through my local machine with ssh connection.But i don't want anyone to access my instance even if he has access to my key file how can i restrict this ?
You can limit network access through security groups like #dream-bold said, or you can get rid of the key file altogether and use an alternative like SSM Session Manager or Instance Connect where you can control access via IAM.
Related
I have inherited a webserver on AWS running an EC2 instance
which is inherited via CloudFront.
I want to SSH in, but there is no keypair assigned to the EC2 instance.
The previous dev is not very helpful - all he told me was "use cloudfront".
Looking into CloudFront - I saw nothing that indicated I could SSH in that
way. Did I miss something?
Is it possible for me to access the instance via SSH without a private key
via Cloudfront?
I would appreciate any help
You can't ssh into your instance through CloudFront. If you don't have the private key to ssh, there are some options you can use:
Try EC2 Instance Connect which is a web-based ssh client. It will not ask for private key, if it works.
Try AWS Systems Manager Session Manager which is also web client. This will work even if the instance was launched without any ssh client. You will need to read up on how to set it up as it requires special instance role, and the ability of the instance to connect to the SSM service.
Use AWSSupport-ResetAccess SSM Automation to reset the ssh key for the instance.
Use recovery instance as shown in the official AWS video.
The best options would be to try 2 and 1. But depending on how the instance is setup, is it in private or public subnet, does it have internet access, is it Amazon Linux 2 or some non-standard AMI, what kind of roles it has, etc., you may need to perform extra steps to make it work.
Options 3 and 4 will require downtime and making backup before you attempt them would be good choice. Options 1 and 2 may work without any downtime, depending on the instance current setup.
I need that all instances that I launch in a public subnet of a VPC can access via SSH without providing a .pem, just with its private IP. Additionally, I need to create an OpenVPN server in one of them so anyone that can access to the subnet via VPN can access to any instance via SSH without providing a .pem using its private IP too.
I do not know if this is possible, but if there is another way to do that I would appreciate it if you could tell me.
Yes, it's possible, you can access your instances without .pem file by using AWS System Manager.
Use Session Manager service of AWS System manager through the AWS console page.
Session Manager: Users who want to connect to an instance with just one click from the browser or AWS CLI without having to provide SSH keys.
A user who wants to monitor and track instance access and activity, close down inbound ports on instances or enable connections to instances that do not have a public IP address.
I am setting up a new EC2 Amazon Linux 2 AMI and am having a try at setting up EC2 Instance Connect as it's preinstalled on my new instance.
From what I've understood the docs to mean, I should be able to create an IAM user, add a public key to that user and then SSH into the box using the IAM user's (public) key without having to create the .ssh folder on the EC2 instance.
What I've done is:
Create a user on the EC2 instance which my IAM user should map to (let's call him bob)
Uploaded my public OpenSSH key to the IAM user
Created a permission policy which allows the action ec2-instance-connect:SendSSHPublicKey (as per the docs)
Once these are all done, if I try to SSH into the box, it doesn't work and in my /var/log/secure I see a preauth failure.
If I create the .ssh/authorized_keys file and set the permissions correctly, everything works fine.
However, my understanding of the EC2 Instance Connect approach is that it gives me a central way to manage public-key based access to my instances.
Am I correct?
Am I missing something in how I'm setting this up?
I'm finding the documentation a little unclear, so some insight would be helpful.
Thank!
EC2 Instance Connect works as follows:
You issue a command that pushes a temporary public key to the instance, such as:
$ aws ec2-instance-connect send-ssh-public-key --instance-id i-001234a4bf70dec41EXAMPLE --availability-zone us-west-2b --instance-os-user ec2-user --ssh-public-key file://my_rsa_key.pub
You then establish an SSH connection to the instance using the private half of the keypair
Within the instance, the EC2 Instance Connect software interfaces with the ssh process and checks whether the SSH key provided matches the public key that was pushed with send-ssh-public-key (and it is within 60 seconds of receiving that key)
If they match, the SSH session is permitted
See: Connect Using EC2 Instance Connect - Amazon Elastic Compute Cloud
EC2 Instance Connect also provides a web-based interface that can both initiate the above process (using a temporary random keypair) and provide an SSH interface. When doing so, the SSH connection appears to come from within AWS, not your own IP address. This is because the web interface uses HTTPS to AWS, then AWS establishes the SSH connection to the instance. This has an impact on security group configuration.
I have an Amazon EC2 instance and a corresponding RDS instance that I want to keep private. I'd like to keep it so that only myself and the sysadmin can access these instances. I don't want to provide access to other developers.
However, one of my developers is working on a project right now where he needs to create/configure his own EC2/RDS instance. I could have my sysadmin perform this work, but I'd rather have the developer do it for the sake of expediency.
Is there any way to configure a group/role/policy in a way that allows me to keep my current instances private from the new developer, but would allow him to create his own EC2 and RDS instances?
Your question appears to be mixing several security concepts, such as 'private', 'group/role/policy' and 'firewalls'.
An Amazon EC2 instance has several layers of security:
First, there is the ability to login to the EC2 instance. This is managed by you, typically by creating users on the instance (in either Linux or Windows) and associating a password or Public/Private. Only people who have login credentials will be able to access the instance.
Second, there is the ability to reach the instance. Security Groups control which ports are open from which IP address range. Therefore, you could configure a security group to only make the instance accessible from your own IP address or your own private network. Your instance might also be in a private subnet that has no Internet connectivity. This again restricts access to the instance.
A person can therefore only login to an instance if they have login credentials, if the security group(s) permit access on the protocol being used (RDP or SSH) and if the instance is reachable by the user from the Internet or private network.
Similarly, an Amazon Relational Database Service (RDS) instance is protected by:
Login credentials: A master user login is created when the database is launched, but additional users can be added via normal CREATE USER database commands
Security Groups: As with EC2 instances, security groups control what ports are open to a particular range of IP addresses
Network security: As with EC2 instances, an RDS instance can be placed in a private subnet, which is not accessible from the Internet.
Please note that none of the above controls involve Identity and Access Management (IAM) users/groups/roles/policies, which are used to grant access to AWS services, such as the ability to launch an Amazon EC2 instance or an Amazon RDS instance.
So, the fact that you have existing Amazon EC2 and Amazon RDS instances has no impact on the security of any other instances that you choose to launch. If a user cannot access your existing services, then launching more services will not change that situation.
If you wish to give another person the ability to launch new EC2/RDS instances, you can do this by applying an appropriate policy on their IAM User entity. However, you might want to be careful about how much permission you give them, because you might also be granting them the ability to delete your existing instances, change the master password, create and restore snapshots (thereby potentially accessing your data) and change network configurations (potentially exposing your instances to the Internet).
When granting IAM permissions to somebody, it is recommend that you grant least privilege, which means you should only give them the permissions they need and nothing more. If you are unsure about how much permission to give them or how to configure these permissions, you would be wise to have your System Administrator create the instances on their behalf. That way, you are fully aware of what has been done and you have not potentially exposed your systems.
Ok, the best explanation about how things works is in #John Rotestein response. But here a few practical suggestions (that must be considered as an complement to John's response):
You can create separate subnets and give permissions to your
developers to run instances in only one of the the subnets using IAM
Policies; But your developers still can reach your instance and you
must configure so/db/application restrictions.
If your company DO NOT use a shared gateway to the internet, you can
define the Network ACL to limit the access to your exclusive network
using your IP address. If you use a shared gateway, you will not be
able to use this solution;
In the second case, one way to limit the access is put your instance
in a private subnet and create a bastion host in your public subnet
to be used only by you (this solution must be configured to your RDS
instances too). The bastion host will be reachable by your
developers, but you can use a specific Key Pair that only you have
access. Just keep in mind that your instances and RDS will not be
available to the internet;
But I think that the simple solution would be create different
VPC's, one for your team and the other for the development team. In
this solution you can restrict access to all VPC resources to your
developers in the "main" VPC. Off course this also means no internet connection to your instances.
We have an issue on our AWS instances that we might have to reset the .pem key due to one of our developers leaving. My question is can I just only allow IP addresses to access each instance or will I need to regenerate another .pem key and reinitialise each instance?
Will the first option be enough to prevent access?
Thank
Yes, you can restrict access by IP. See "security groups".
You should update your ssh keys and propagate them to your EC2 instances. Ideally, don't use shared credentials (like ssh keys, AWS console access) because of situations like this.