I recently dove headlong into the chaos and excitement of AWS, and this article assumes that you've made the decision to move some or part of your IT infrastructure to AWS. In my first article, we discussed setting up AWS instance while moving over an existing Magento site. This is a common request, as many Magento business sites are being targeted by cloud providers.
My motivation for writing these articles is my overwhelming frustration with the documentation available to most people. It shouldn't take an act of the IT big brain to actually do something on AWS. I found that AWS documentation is good for one thing — to let me know that certain tasks can be done. Otherwise, unless you are Linux server admin and have been doing this work for years, Amazon's documentation is gibberish.
Once again a few things to understand and take head to in this article:
You are not afraid of terminal or command line.
You already have an EC2 instance.
You know something about command line directives on your designated OS.
You just want to create a new user and give that person SSH access to your instance so they can work, etc.
Your instance is an Ubuntu 14.04 standard.
That you have access to su or root privileges.
Part I: Log Into Your Instance From Command Line
Open your terminal, by typing:
sh -i /<path to your certificate>/<your filename>.pem ubuntu@<your instance>us-west-2.compute.amazonaws.com
Once you have logged in, change privileges to root or su (substitute user).
Now, if you are like me, you just got your instance set up and are breathing a sigh of relief because really it didn't need to be that difficult.
In my example, we have not assigned root any additional password because we use key-pairs. But because we only allow public-private key pair logging, we feel some security. You should set up your solution however you feel is right for your organization.
sudo su - <now if you assigned a password to this it will prompt you>
sudo su - <name of user> : You will need this information for setting up your new user later.
So, your screen should say something like:
root@ip-<your IP address>:~#
Or whatever your root user account may be (again, if you are like me you just got the instance up to make your boss or client happy).
Part II: Adding the User
This one is pretty straightforward, and you may have done it before, but let's do it.
If you don't already have a user created then follow:
You can also add some control parameters such as:
adduser -c "whatever text" -s /bin/bash -m username
-c is a comment that appears in the .psswd file you never see, so it only makes a difference if you have lots of users.
-s by default is bash.
-m makes a home directory the username.
Again, when you type in adduser, Ubuntu does this for you by default, so no worries. Do not add any passwords, just hit the enter key.
Now, if you have tried this excercise and you have had problems, then you most likely already have a user, so this is redundant.
So, now you have created the user, and this is where Amazon documentation screwed me up.
Here's my workaround.
Part III: Generating the private/public key:
Amazon would suggest that you use their tool and generate a key-pair. This generates a .pem file that you probably used to log in first. Unfortunately, that is where I got hung up on the new user. Trying to get that file to work was leading to all sorts of problems.
So let's skip it for the sake of my article and sanity.
In order to avoid passwords and that nonsense, we want to generate a public/private SSH key-pair. The Internet is replete with examples that just don't apply to where we are at. They are close, and if you want, you can spend hours messing around with all sorts of possibilities.
ssh-keygen -b 2048 -t rsa -f key -C mynewuser
At this point, you will have two files created — key file and key.pub file
So what the heck are these files? They are the public key and private key that you will use to log in with your key pair. The key file is the public that gets shipped off to your user, and the other file is what you end up putting in the new user account. It is assumed that you don't want to dig too deep into SSH mechanics. (You wouldn’t be reading this if you already knew that stuff, and you have other work to do.)
Part IV: Adding the Key to Your New User:
Before we move to the next few steps, we need to switch your new user. Remember the su command:
su - mynewuser
Now move into your new users directory by typing:
Once you are in the directory, you need to make a hidden directory. To do this, precede the name of the directory with a period. Because we need to do this for SSH access — Linux looks for this directory by default — you shouldn't have to do anything.
Once that is created, you need to do a few things.
The first is you need to switch back to your su or root user and copy the key.pub file into the newly created .ssh file
sudo su - or whatever name you may have created with root.
Now make sure that you are in the correct directory by typing
This gets you to the root where you created the key file.
This will show you your files. If you don't see those files, then you need to find them. You can do a history command and see all of your prior commands and look for the command that proceeds the ssh-keygen command and hopefully that will show you where the file is located or use the find command.
Assuming you are in the correct, directory copy them to the .ssh file
cp key.pub (not the other file) /var/home/mynewuser/.ssh
This will copy the file into the correct directory. But we are not done yet. We now need to create a new file and copy the contents of key.pub into it. There are many ways to do this, but I will stick with the most common method (if you do many searches on Google, this method tends to come up as it combines a few commands).
The first thing we need to do is switch users again:
su - mynewuser
Now lets get to the .ssh directory:
If you did things correctly, you should be able to do an ls command like above and see the key.pub file.
Assuming that it is there:
cat > authorized_keys < key.pub
Basically, this file creates and adds key.pub to authorized keys.
Now we need to set permissions, or SSH will not work:
chmod 0700 ~/.ssh chmod 0600 ~/.ssh/authorized_keys
This will set the permissions correctly so that your SSH key file will work.
Now that you have set up the new user with the correct file and permission, you need to get the key file (remember that one) to the user so that they can test.
Part V: Transfer the Public Key to the User Who is Going to Use This Account
I found that you can FTP it, use scp command or frankly just copy the contents and paste them into a new file. Normally, you could use scp key xxxx@xxxxxx:~/ and that would copy it to the root directory of the user. However, I had some difficulties as I was trying to download this to my Mac, which was set up a bit differently. So, to get around the security hurdles, let's just copy and paste into a new file on my local machine.
Or whatever your root is.
Or you can use your favorite editor.
This should display your public key that your user will need. Highlight the contents of the file and copy.
Now you can open another terminal window so you don't need to log out of your instance. Wherever you want to put this file, go to that location.
and paste all of the contents. Save the file and exit the editor.
Now if you try to SSH in, you will get a nasty permissions error, so we need to change that.
chmod 0600 nameofkey
OK. You should be done unless there were some permission issues that you may have run into.
ssh -i <directory of key location>nameofkey mynewuser@<IP address of your instance>
That should get you in.
This all seems somewhat basic, but as I have come to realize, that the basics are often the most complex for people who don't spend their lives doing this type of work (my hat's off to you people). To others who need to get a job done and want to move onto other projects, then spending time searching the net for what to do is just a waste and frustrating.
Of course, your new user is just that — a new user with no permissions. So, you will need to add the new user to a group that has whatever permissions.