I have an EC2 instance, where the backend for my Mobile App is hosted.
My developer needs access to my server, in order to upload the new code and I guess test it also.
Now, I do not want to give him FTP details, so here is what I did:
Created a new Linux User
Created a new Key pair from the EC2 Console
Created a .ssh directory
Change the file permission to 700 (so only file owner can read/write/open the dir)
Created authorised_keys with the touch command in the .ssh directory
Changed the file permission to 600 (so only file owner can read/write the dir)
Retrieved the public key for the keypair
Add the public key in the authorised_keys
Now I can share the new generated PEM file with my Developer along with the username and my EC2 host IP address.
But I don't understand why not I can directly to this by creating an IAM User from the AWS Console and set his permission accordingly?
I am really confused because I first wanted to do it the IAM way but everyone suggested I go with Linux user - isn't it the same thing?
Also, I shall delete this user entirely once he is done with the work - right?
Furthermore, I don't understand something... after doing all this and setting up the new Linux user, I am able to connect to my server using the Linux Username and Unix Password only - without using the PEM file that I have created - how is that?
Also, technically that new Linux user can simply delete my main Linux user... I mean I can simply right-click on the User and press delete via Filezilla for e.g. How can I prevent this from happening? Even though that wouldn't matter, as he could also simply delete my entire backend?
I have the following on my server now:
Home Folder
Home Folder > appBackend
Home Folder > mainLinuxUser
Home Folder > newLinuxUser
And last but not least, why is everyone always saying to never share the Private PEM file with anyone.. at the end of the day, if I only allowed specific IP address to connect to my EC2, then I should never be worried about anything? Same as I have done for my MongoDB - only if I add the IP address, only then that person can connect and view my Database. So with all the previous developers, I had shared my DB Configuration, it won't matter since their IP is not in my Security Group anymore - am I right?
Sorry, I am new to all this and I am trying to get my head around it all. I appreciate any help!
Creating Linux user vs IAM user :
IAM Users are for users who can access AWS resources based on permissions you provide. That means if you create IAM user with full access to EC2 and provide the details to your developer, he/she can login to AWS and have full access to EC2. He/She can create,start/stop, reboot, terminate your EC2 servers etc.
IAM Users/Groups are created to restrict access to AWS resources such as EC2, S3, VPC etc. and not for OS which runs inside EC2.
Yes, delete the user and keys once the work is done.
For login to linux sever, you can use either username-password or username-key. Check your user settings if you have set login with password. Use "--disabled-password" or similar when creating new user. Refer it here : https://aws.amazon.com/premiumsupport/knowledge-center/new-user-accounts-linux-instance/
Check if you new user has root or sudo access. If you have provided sudo or root access, new linux user can execute such actions.
Note that, it is a best practice to delete the default root user on EC2 once server is up and running. ec2-user or ubuntu. Reason being, if your pem key which you had used when creating EC2 is compromised, your server is compromised. These default root users are known to everyone unlike specific users you'll create. Hence better to delete them.
Also follow the least access principle and provide only the least required access to new user. This means, you should create user as per the need or activity and restrict access to only that activity. Eg, if your user needs to only copy the files to/from within specific folders, set your user with a group and assign permissions to required folders. Do not provide any sudo access to it.
Similarly, you can create an admin user with access to sudo, however, make sure this user is not shared to other developers.
Related
Why an external user with guest role cannot access an internal repo when it is granted to?
Objective
I have a problem giving permissions in gitlab. I want to have externals users with guest (role) permissions to download one internal project.
The gitlab documentation says the following:
Users with Guest role can download the project only if it is public or internal.
Externals users can only access projects to which they are explicitly granted access, thus hiding all other internal or private ones from them. Access can be granted by adding the user as member to the project or group.
Environment
I have the next configuration in gitlab:
One user created as external user named userexternal.
One internal project named internalproject.
The internalproject has userexternal as member with the guest role.
Expected behaviour
userexternal can download (clone, etc) the internalproject because he has access granted.
Actual behaviour
userexternal cannot download internalproject. The page returns a 403 error (forbidden access).
Cloning into 'internalproject'...
remote: You are not allowed to download code from this project.
fatal: unable to access 'https://userexternal:PASS#example.com/internalproject.git/': The requested URL returned error: 403
This may not apply directly to your situation, but we wanted to do something similar with a client. We created deploy keys with read only access to one project in our gitlab. Since the ssh keys are only associated to that project and not to a user, they can't touch anything else besides that repo. Mixed with the read only option, they can only pull and clone.
We wanted to keep this user separate from any other account so we created another user within our system with admin capabilities (only drawback), a random password that they won't be given, no ssh login keys, and we ticked the external user checkbox (yeah somehow you can be an external admin?).
Again, not ideal but a workaround... :(
Cheers
I created a user account on Amazon Linux Instance with root user. I found that if I create a user account(Example: ec2-user) that account will not have execute and write permissions on Hadoop Files System, Hive, Pig and other tools which are installed on Amazon EMR. If I have to give them explicit permissions I have to create a group which has permissions equivalent to superuser(root) account and add users to that group. Is there any other way I can set up access for those accounts to HDFS, Hive and Pigs etc.
Also while logging in as user the Linux command prompt is not prompting to enter any password even though I gave password for the user account while creating it. Is there anything configuration changes I need to make in /etc/ssh/sshd_config file?
Your question is not that clear to me.
But, let me attempt with whatever I suppose I understood.
Hadoop when security is enabled needs to have security for each user. It seems your user needs a separate space for writes and executions i.e. a Home directory.
First login as 'hdfs' user in a terminal and then create a home directory for your user in HDFS. Please check if you have a directory called /user/{yourUser}. If, not create that. Then, make sure you make {yourUser} the owner of /user/{yourUser}.
I am trying to come up with a best approach for creating a user called appuser in Ubuntu. The reason to create this user is:
1. This user will be used to install and start applications like Tomcat, MySQL etc.
2. Other users will login to system using their account. Then using su appuser, they should be able to login to this user and manage tomcat, mysql etc.
What is the best practice to create this user?
1)Give 755 permission to mysql and tomcat folder so any one can read and execute application but dont write or modify the data.
2)also provide grant permission to mysql DB for users.
OR
those having full permission to application of tomact or mysql other user(new users) also part of that group.
OR
you can use ACL (access control list) for the same.
I have a dedicated Linux web server with many user accounts on it. The user accounts are all located in /home/[userid] directories. I am able to create Perl scripts that run within each of my users’ accounts that can access files only within their own account, but now I need to create a script that can run “above” the users’ accounts and be able to access a file within any specified user’s account.
Currently, I have a script that uses Net::FTP to retrieve the needed file from each account so I can extract the necessary data from it, but of course, it’s slow to FTP into every account. Since the accounts are merely directories on the server, I’m looking for a way to run a Perl script in a way that it can access each account directory and simply open the required file and return the requested data for the specified account.
How can I accomplish this?
You should login as a user that has access to all the user directories (e.g. root). For security reasons, it might be safer to use sftp or some other encrypted connection.
I have a sudo account (not root) on several CentOS servers. We would like to share the cluster with other uses who do not have an account for research purpose. (By share I mean users can reserve a time slot to use the cluster exclusively.) But setup an account in the OS for each user is too annoying. Is there a good way to grant them authority to read/write/execute their own files during a certain period of time? I am thinking something like temporary username and password that they can use to login through some interface (like a webserver) I offered. And the username and password will expire after when their reservation. Any idea?
You can share your unix user account among several users, by using SSH key authentication.
In a nutshell, each user generates a public/private key combination. The allowed public keys are then listed in the following file on the shared unix acount:
$HOME/.ssh/authorized_keys
I'm not aware of a mechanism to control when users are allowed to login. Presumably one could have a cronjob that swaps different versions of the authorized_keys file, dependent on the time of day. (Seems like over engineering the solution, users can easily over-ride this kind of restriction).
Articles:
http://wiki.centos.org/HowTos/Network/SecuringSSH
http://www.ualberta.ca/CNS/RESEARCH/LinuxClusters/pka-putty.html