Launch an EC2 instance
Create a separate key-pair for SSH access
Provide this key-pair to few developers (say dev1, dev2, dev3)
dev3 leaves the company
How to revoke permissions for a dev3 user in such a case
When SSH is used to connect to a Linux computer, a private keypair is provided.
The Linux system will then check in the user's home directory for keys that are authorized to login. For example, if the user is ec2-user, it will look in /home/ec2-user/.ssh/authorized_keys.
If the matching public keypair is found, then the user is permitted to login.
Therefore, the recommended process is:
Each user should generate their own keypair. They can do this in the EC2 management console, or on the command line using ssh-keygen. They should keep the private keypair to themselves, but provide an Admin with the public keypair. This is done to ensure that nobody else has ever seen the private keypair (it's like a password).
The public keypair should be copied to Linux computer and added to the appropriate user's ~/.ssh/authorized_keys file. This could be a shared user like ec2-user, or it could be a separate login for each user.
If somebody leaves the company, simply remove their keypair from the authorized_keys file.
Since you have been using a shared keypair, you should remove that keypair immediately. Then, ask authorized users to create their own keypair, provide it to you, and then put them in the authorized_keys file.
Related
I am new to Google Cloud, but I have followed all the steps below by looking at some documentations and forums. Not sure if I am missing anything with the configuration or what. Any help would be appreciated
Created Instance on Google Cloud
Downloaded PuttyGen and generated key
Updated key on instance as well as Project metadata as well
Trying to connect from Putty I am getting following error
Not sure what is happening. I have tried all help from other posts from stackoverflow and google groups as well. But nothing seems to change for me. It could be simple that I am not looking at?
I've tried to follow your steps and found no issues.
Please have a look at the commands below:
create test VM instance;
download PuTTY and PuTTYgen ;
follow the documentation and generate SSH keys:
Click Generate and follow the on-screen instructions to generate a new key. For most cases, the default parameters are fine, but you must
generate keys with at least 2,048 bits. When you have finished
generating the key, the tool displays your public key value.
In the Key comment section, replace the existing text with the username of the user for whom you will apply the key.
Optionally, you can enter a Key passphrase to protect your key.
Click Save private key to write your private key to a file with a .ppk extension.
Click Save public key to write your public key to a file for later use. Keep the PuTTYgen window open for now.
follow the documentation Adding or removing project-wide public SSH keys to add public key project wide at the Metadata page:
Use project-wide public SSH keys to give users general access to a
Linux instance. Project-wide public SSH keys give users access to all
of the Linux instances in a project that allow project-wide public SSH
keys. If an instance blocks project-wide public SSH keys, a user can't
use their project-wide public SSH key to connect to the instance
unless the same public SSH key is also added to instance metadata.
or follow documentation Adding or removing instance-level public SSH keys to do it at the instance level:
Instance-level public SSH keys give users access to a specific Linux
instance. Users with instance-level public SSH keys can access a Linux
instance even if it blocks project-wide public SSH keys.
add private key to PuTTY and connect to VM instance using username you use at the Key comment section while generating the key, I was able to reproduce your error by using any other username at this step.
In addition, have a look at the OS Login feature:
OS Login lets you use Compute Engine IAM roles to grant or revoke SSH
access to your Linux instances. OS Login is an alternative to managing
instance access by adding and removing SSH keys in metadata.
In the AWS EC2 console/service, you are able to view several key pairs - what exactly is the purpose of these key pairs? Are they relevant to the ec2 instances or the rds?
Keypairs are not actually related to AWS or Amazon EC2. They are related to Linux.
When using Linux utilities like ssh and scp, keypairs are used to authenticate users. For example, if you use this command:
ssh -i key.pem ec2-user#IP-ADDRESS
The receiving Linux operating system will look in the /home/ec2-user/.ssh/authorized_keys file. It will check whether the private keypair supplied in key.pem matches a public keypair in that file. If they match, then the connection is permitted.
To make this process simpler, there is some software installed in Amazon Linux that will accept a nominated keypair and install the public half in the the authorized_keys file. This makes it easy to initially login to the instance.
You are then welcome to modify the contents of the authorized_keys file to add/remove any keypairs you wish. You can also create new users on the operating system and add appropriate keypairs to their authorized_keys file.
Common corporate security practices involve each staff member generating their own keypair (so only they have the private keypair), then providing the public half of the keypair to the IT department. Whenever access is requested to a particular Linux computer, the IT people can add their public keypair in the appropriate location. This then grants the staff member access to the computer.
The Amazon EC2 service provides an easy way to generate keys and it will also keep the public half of the keypair, which can be used to add keys when an instance is launched. However, you do not need to keep these keypairs! If you prefer to manage the keypairs yourself (as suggested above), then you do not need to keep these in AWS beyond the initial launch of the instance.
Amazon RDS does not allow users to connect via SSH, so keypairs are not used with Amazon RDS.
Bottom line: Keypairs are used by Linux computers to authenticate users.
From AWS documentation:
Amazon EC2 uses public key cryptography to encrypt and decrypt login information. Public key cryptography uses a public key to encrypt a piece of data, and then the recipient uses the private key to decrypt the data. The public and private keys are known as a key pair. Public key cryptography enables you to securely access your instances using a private key instead of a password.
When you launch an instance, you specify the key pair. You can specify an existing key pair or a new key pair that you create at launch. At boot time, the public key content is placed on the instance in an entry within ~/.ssh/authorized_keys. To log in to your instance, you must specify the private key when you connect to the instance.
So, we can see what the purpose of the key pair is. It is used to ensure safe login and connection to your EC2 instance.
I have two EC2 instances in same subnet but I when I am trying to ssh from one instance to another I am getting publickey denied message, it does not prompt password
[root#ip-10-0-21-156 ~]# ssh testuser#10.0.21.170
Permission denied (publickey).
By default, EC2 instances are configured to provide SSH authentication via public/private keys. So, just like you needed a private key (you likely downloaded the .pem file when you created the IAM keypair) installed on your local computer in order to SSH into the instance, you also need a private key installed on the instance in order to SSH from that instance into another instance.
What you didn't see behind the scenes was that when you launched the instance and specified the key-pair name, EC2 let you download the private key (.pem file), automatically created the user on the instance (e.g. on the Ubuntu AMI, the username is 'ubuntu' and on the Amazon Linux AMI, the username is 'ec2-user') AND it put the public key that matches the private key into the ~/.ssh/authorized_keys file. All of that needs to happen before you can SSH into an instance.
So, assuming you launched the two instances with the same keypair, in order to SSH from instance A to instance B, everything has been done for you EXCEPT for putting the private key (the .pem file) into the ~/.ssh directory. AWS considers keeping the private key on the instance a security risk and therefore does not do it automatically. So, simply put the private key into the .ssh directory on instance A and then add it to your keyring or you can specify the key in the ssh command like so:
ssh -i ~/.ssh/PRIVATE_KEY.pem USERNAME#INSTANCE_B_LOCAL_IP
All that said, it's generally a bad idea to keep private keys for other instances on an EC2 instance and if you find yourself needing to do that, you should likely rethink your architecture for whatever it is your doing (i.e. there are probably better ways of doing it).
Additionally, you really shouldn't be using the EC2 created user account (i.e. ubuntu# or ec2-user#) for normal day to day stuff or even to perform maintenance or other sysadmin work. You should really create your own account, because the EC2 created account is essentially a root account.
AWS recommends continuing to use public/private key authentication for all accounts, however you could switch to use password-based authentication and then not need to worry about the keys. This is inherently less secure than using key-based authentication, however given strict password requirements, you could increase security.
The only thing you will need to do when creating additional accounts (either password-based or key-based), is to make sure your personalized account has sudo access so you can sudo to do things that require root access. In Ubuntu, you can do this by adding the following line to the /etc/sudoers.d/90-cloud-init-users file:
USERNAME ALL=(ALL) NOPASSWD:ALL
While you're there, consider disabling the sudo access for the EC2 created username. Even though no one else will have the key, everyone will know that there is an ubuntu account that has sudo access. Just like with passwords, knowing the username is a substantial part of a hackers job.
Hope this helps.
I have an EC2 production server running and i have a key.
Now we have some developers that need access to the server, but for security reasons i don't want to share our private key to the server because we will loose track of who has access to the server.
I have searched in amazons documentation for answers to this, but i can't find any solution there, i have also searched the stack overflow but can't find much other than people who lost there key pair.
Is there any way to make a temporary key for the EC2 instance? or any other way i can grant them temporary access to the server?
The same account cannot be shared by using different keys. The only way to give access is to create a new user and a new keypair. Once you decide the access has to be revoked, you have to delete that user. Adding and deleting an user is explained here: Managing User Accounts on Your Linux Instance
Keypairs are used to grant access to Amazon EC2 instances. They are public/private keypairs, typically randomly generated by EC2 but existing keypairs (or more specifically, the public half of the keypair) can be imported into EC2.
They are used as follows:
Windows: When starting Windows from a standard Windows AMI, a utility called Ec2Config randomly generates an Administrator password, encrypts it using the public half of the keypair, and passes it back through the System Log. Users must decrypt it using their private key. They can then login to Windows.
Linux: When starting Linux from a standard Linux AMI, the public half of the keypair is copied to .ssh/authorized_keys. Users can login via ssh by providing their private key.
(The reference to a 'standard' AMI is intentional -- AMIs created by other people will not necessarily have these utilities installed.)
In both situations, it is advisable that users then modify their instance to use their normal security standards. For example, Windows users should change the Administrator password, create additional users or, preferably, attach the instance to an Active Directory domain. Linux users should create additional users and install their standard keypairs in the authorized_keys file.
There should be no continuing need to use keypairs after the initial launch of the EC2 instance. Users should be using their own Username and password/keypair. It is not good practice to keep using the same password/keypair as initially created when the instance is launched.
Just think of the Amazon EC2 server as a "normal" server. What security would you normally put on a server to ensure that authorized users can login, but unauthorized users cannot? Go ahead and do the same thing with EC2.
I've created a user "developer" on my amazon ec2 instance with restricted privileges and I've assigned him a password. Now I want allow him to connect to my instance (via ssh or sftp) and let him do something small like upload some files in a specific folder and I don't want let him play with my server like an administrator. How can I do it if I provide him the instance .pem key?
Can I give him the .pem key and force him to login using the developer account?
Accounts granted in AWS (with IAM) are independent of user accounts on a given instance. IAM account give the user access to parts of AWS defined by the policy associated with the group or user.
If you want to give someone access to the instance, you can have them generate their own personal keypair (ssh-keygen or puttygen). You will take the public part of the keypair and add it to the ~/.ssh/authorized_keys file of the user you want them to login as.
You can use IAM groups and users. The documentation is here.
IAM allows you to generate separate access keys for users with restricted usage rights.
There was a step missing in the leading answer. I added: You also need to add the public key on the AWS console under "Network & Security" -> "Key Pairs".
I'd add this as a comment, but don't have enough cred points yet.