DEV Community: Tobi Akanji

Add New User to EC2 Linux Instance with Google MFA: Ubuntu

Tobi Akanji — Wed, 19 Jan 2022 21:52:52 +0000

Note

This tutorial is not for absolute beginners, but persons with some experience in Linux, CLI and a bit of cloud technology.
The actions listed here are to be carried out by a superuser (preferrably the root user), unless otherwise stated within context.
Where your machine or instance does not have the nano text editor, use vi (for the vim text editor).
<...> represents placeholders in code snippets and configurations.
[...] represents optional parameters in code snippets and configurations.
Ensure you are logged in to the EC2 instance as a superuser.

Get Key Pair for The New User Account

You can generate a new key pair, or use an existing one.

To generate a new key pair

aws ec2 create-key-pair \
    --key-name <key-pair-name> \
    --key-type rsa \
    --query "KeyMaterial" \
    --output text > <key-pair-name>.pem

Ensure to get this file and keep it in a safe place where you will not lose it, e.g.:

in a secure and accessible cloud storage.
in an accessible key vault.

If your local machine is a Linux or Mac, ensure only the current user has access to this file

chmod 400 <key-pair-name>.pem

Retrieve the public key from the key pair

ssh-keygen -y -f /<path_to_key_pair>/<key-pair-name>.pem

If you would be using the same private key as that which was used to launch the instance, you can get the public key by running the follow command

TOKEN=`curl -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" –v http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key

Copy the public key and keep it for later use.

Create New User

Switch to root

su -

The above might request for password that you did not set, nor do you want to keep inputting passwords. In such situations, go with the below snippet

sudo -i

Add new user

sudo adduser <username>

If user is to be a superuser

sudo adduser <username> --disabled-password

Make User A Superuser

Add User to Sudo Group

usermod -aG sudo <username>

-aG: Append to group.

Verify user belongs to the superusers group

groups <username>

Update The Superuser to Not Use Password

Superusers are usually not expected to need password for access once authenticated. Hence, the convention overlooking password authorization for superusers.

Open the sudo permissions file

sudo visudo

Add this to the opened file in the editor, save the file and exit the editor.

<username> ALL=(ALL) NOPASSWD:ALL

To prevent the need for using a password for the user at any password prompt, delete the user password

sudo passwd -d <username>

Henceforth, just press Enter whenever there is a password prompt, and you get authenticated.

In the case where the user is not a superuser, and you used the --disabled-password flag you can set a new password for the user by the root user

passwd <username>

Follow the prompts and press Enter when done.

Implement SSH Authentication

Switch to the new user

su - <username>

Add .ssh directory to the new user’s home directory:

mkdir .ssh

Create the authorized_keys file

touch .ssh/authorized_keys

Restrict read-write access to the new user

chmod 600 .ssh/authorized_keys

Update the new user account credentials by pasting the public key into the file

nano .ssh/authorized_keys

Save the file and close the editor.

You can also verify the user belongs to the superusers group

id

You should get a similar output as follows

uid=1004(<username>) gid=1004(<username>) groups=1004(<username>,sudo)

Implement Google Auth MFA

Download the Google Auth mobile app on your mobile device if you do not have it. For Android, it is available on Play Store.

Ensure you are on the new user, else switch to the new user

su - <username>

Install the Google Auth app

sudo yum install google-authenticator -y

Initialize the app

google-authenticator

Open the Google Auth mobile app, press the plus button ➕ and scan the QR code in the CLI.

You can rename the new authentication on your mobile app to something more intuitive.

Answer the prompted questions in this manner

Do you want authentication tokens to be time-based (y/n) y

Do you want me to update your "/home/ec2-user/.google_authenticator" file (y/n) y

Do you want to disallow multiple uses of the same authentication token?
This restricts you to one login about every 30s,
but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n) y

# Select ‘n’ for the next question for 3 valid codes in a 1:30-minute window
By default,
tokens are good for 30 seconds and in order to compensate for possible time-skew between the client and the server,
we allow an extra token before and after the current time.
If you experience problems with poor time synchronization,
you can increase the window from its default size of 1:30min to about 4min.
Do you want to do so (y/n) n

If the computer that you are logging into isn't hardened against brute-force login attempts,
you can enable rate-limiting for the authentication module.
By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

Configure SSH to use the Google Pluggable Authentication Module

sudo nano /etc/pam.d/sshd

Append the following to the opened file in the editor

auth required pam_google_authenticator.so [nullok]
auth required pam_permit.so

Disable the password requirement by ensuring this line commented out

#auth       substack     password-auth

Change the SSH configuration to prompt for a second authentication

sudo nano /etc/ssh/sshd_config

In the opened file, modify as follows

#ChallengeResponseAuthentication no
ChallengeResponseAuthentication yes

In the same file, let SSH know that it should ask for SSH key and verification code.

AuthenticationMethods publickey,keyboard-interactive

Save the file and close the editor.

Restart the SSH to for the changes to take effect using either

sudo /etc/init.d/sshd restart

sudo service sshd restart

Test Connection and Privileges

Open a new terminal on your local machine.

SSH into the instance with the new username and the associated private key

ssh -i /<path_to_key_pair>/<key-pair-name>.pem <username>@<instance-public-dns-name>

It should prompt you for a verification code. Open your Google Auth app to get the latest verification code for this instance, input it into the text box, and press the Enter key.

You should now be logged in to the instance as the new user who can perform sudo activities.

Conclusion

It sure was a journey coming this far, and I can but say, well done and congratulations!!! You have found something that works: for Ubuntu and most other Linux instances (some needing little tweaks).

Thanks for reading through. But do not forget the references below: they could open you up to more possibilities beyond the scope of this tutorial.

As much as I have practiced this over time, and tried out different things with different documentations, your contributions are very welcome in the comments.

Enjoy exploring, learning, and growing!!!

References

Title	Website
Add New User to a Linux Instance	https://aws.amazon.com/premiumsupport/knowledge-center/new-user-accounts-linux-instance
Setup Multi-factor Authentication	https://aws.amazon.com/blogs/startups/securing-ssh-to-amazon-ec2-linux-hosts
Create and Retrieve Key Pairs	https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html#having-ec2-create-your-key-pair
Set or Change User Password	https://www.cyberciti.biz/faq/linux-set-change-password-how-to
Poster image	Freepik

Three (3) NodeJS Lessons I Have Learned In 2021

Tobi Akanji — Sun, 01 Aug 2021 23:49:55 +0000

Hello dear reader, happy second half of the year 🎉! It has been quite a year for many of us, and within the past months, we have experienced situations which we eventually learnt from and gained some wisdom.

From the tonnes of things I learnt in the earlier six (6) months of the year 2021, I would love to share some of them with the entire Dev community, that is, you inclusive. So, let's go ✈️!

1. Pass In Required Variables Directly In An Object

When it comes to chaining object properties to get a required value, many times we can never be too sure that even the very first variable, which is supposed to be an object is even defined.

Take for example v1.r1.r2.

v1 could be anything including null and undefined
r1 might not be a defined variable of the object v1

Notice that if either 1 or 2 is true, the chained variable would throw an exception for Property of undefined.

Now, say we pass this chained variables into an object as a key-value as thus, given either of the two (2) above listed conditions

{
  p1: v1.r1.r2
}

The error will be thrown from within the scope of the object, leaving the error message and error stack behind.

Hopefully we have a logging system across the modules (.js files) in our app, all the that the log will contain sounds something like

WARNING: 😕 Hey, there was an error somewhere around, go check it, and maybe fix it!

Except you have only three (3) statements that make up your project, then you most likely do not even have an idea of what you is happening, lest even what to do.

To fix this, the right approach is to define the required variable outside the scope of the object. For example

const val = v1.r1.r2

const obj = {
  p1: val
}

This will help with logging and debugging, because the exception will be thrown and caught with the error message and stack.

NOTE: Chaining variables (property or method) on a variable that is undefined will throw an exception. Usually, NodeJS will log the error trace to the console (default) and/or wherever else specified. Therefore, these logs should contain information that is intuitive enough for easily approachable debugging.

Another way to avoid this exception is to check the defined state of each chained property, that is, property after property. For example

const obj = {
  p1: v1 && v1.r1 && v1.r1.r2
}

2. Never Pass Undefined Value To Knex `where` Function

Passing an undefined value to a column in a Knex where function will throw an exception. This is quite similar to lesson 1, in that, if we apply some of the principles we learnt there, we could somewhat avert the feasibility of encountering this issue.

You might expect that such query should take the default value specified in the schema; right? Which in many cases will be null. Unfortunately for that assumption, it is not so, and it is outrightly stated in the documentation.

Where Clauses

...
Important: Supplying knex with an undefined value to any of the where functions will cause knex to throw an error during sql compilation...

Ouch! Sorry, you did not see that coming. But well, exceptions are errors you do not expect, nor do you specifically write code for, although we should always prepare our projects (codebases) for them.

3. Log Errors/Exceptions With Directives Included

Not all error logs contain enough information for instant debugging, intuitive debugging, refactors or fixes. For this to occur, the error log should include enough information, which anyone can use to streamline the issue.

For this reason, it will be more effective to construct the error log in such a way that anyone including you and anyone with authorized access to the logs, can determine what the exact issue is, and the next cause of action, in the case that any issue arises.

Properties such as source and action in addition to a log will be very helpful in this regard. For example:

{
  "message": "Specified column does not exist", // Optional
  "source": "database",
  "action": "Update User Password",
  "error": "\"the entire error stack\""  // Could represent both error message and stack
}

Conclusion

For the meantime, these are few of the things I learnt while working on NodeJS projects this year, which I have been eager to share. Kindly share your thoughts on the three (3) lessons noted above.

I would gladly appreciate that you share your own discoveries likewise in the comment section, as I look to feature them in future iterations of this article.

Thanks for having me! 👍

Build and Host Containerized Micro-Services

Tobi Akanji — Wed, 27 Jan 2021 17:36:49 +0000

In this tutorial, we would be deploying the main components of a containerised node app, as services on an AWS server.

We will go through three (3) major steps here, including:

Containerization
Docker-compose
Proxying

Connecting To Your Server Via SSH

$ sudo ssh -i <path>/<to>/<.pem file> <user>@<id>.<region>.compute.amazonaws.com

Tools

The minimum requirements to follow this tutorial are:

CLI (e.g. Bash, Powershell…)
Docker
Docker Compose
NGINX
AWS-CLI

For general CLI activities, I use Git Bash.

Docker

Docker will be used to containerize our application, which in this case, is a microservice.

Install docker

Docker Compose

Docker Compose will be used to define how microservices for your application will relate.

Install docker-compose
Create a docker-compose.yml file a folder at your home (~) directory. E.g.

cd ~ && mkdir my_new_app && touch docker-compose.yml

NGINX

NGINX will be used to define how the outside world will be able to relate to, and secure our application.

Install NGINX

Containerizing Your Microservices

Open your CLI tool and go into your app root directory.

$ cd <path/to/app/root/directory>

You might want to confirm your current directory first, to guide on how to get to your root directory, run:

$ dir

In your app root directory, create a Dockerfile named Dockerfile with no file extension.

$ touch Dockerfile

Ensure that whatever you are using to create the file does not add an extension to the Dockerfile. You can confirm this by running the following command on your current directory:

$ ls

Setting Up The Dockerfile

The minimum requirement for a Dockerfile is

FROM node:14.15-alpine
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["npm", "start"]

To allow for further process automation e.g. database migration, the actual commands to be executed when the container starts running, will be in a shell script (.sh file) created in our app e.g. in the deploy.sh file below

#!/bin/sh
cd /app
npm run migrate:up
npm run start

The Dockerfile will be composed similar to:

FROM node:14.15-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm install
COPY . .
RUN chmod +x deploy.sh
ENTRYPOINT ["./deploy.sh"]

FROM: Defines our base image, that is, the foundation upon which we are building our application/image. This could be the programming language (e.g. python), runtime (e.g. node), OS (e.g. ubuntu) etc.
The argument goes with the syntax <name>:<tag>.
WORKDIR: Specifies a folder in our docker image where we will place our work files. Usually you should place your work files (codebase files) in a folder, conventionally ./app.
COPY: Copy files and folders from our local machine to a folder in our docker image. The last argument indicates the docker image folder we are copying to.
RUN: We use this to run shell commands.
CMD: Here, we define the command we need to run the application.
ENTRYPOINT: This is a docker command that executes the exec command when the container begins to run.

The line RUN chmod +x deploy.sh, is used to switch the permission for the specified file deploy.sh, which will be used to run the bash script. Without switching the permission, it is most likely that the current user will not be able to run scripts in the container, on the server.

Note: a migrate:up script has been set in the package.json

The first line, #!/bin/bash defines the symbolic link, and is compulsory, so that the server knows what shell to symbolically link to.

Building The Image

On your CLI, still at your app's root directory, run:

$ docker build -t registry.tboyak.io/my_own_app:1 .
$ docker tag my_own_app:1 registry.tboyak.io/my_own_app:1

...to simply build the image.

$ docker run -p <port>:<port>

...to build the image and spin-off a container.

Forking The Image For A Remote Docker Repo

$ docker tag my_own_app:1 registry.tboyak.io/my_own_app:1

Pushing to Docker Hub

For our app to be accessible online, we would need to push the image of our application to Docker Hub. To do this, we run:

$ docker push registry.tboyak.io/my_own_app:1

Setting Up The Docker Compose

The minimum requirements for a docker-compose.yml file with an app and a database is as setup below:

#docker-compose.yml

version: "3"
services:
  my_own_app:
    // build: ./
    image: registry.tboyak.io/my_own_app:1
    ports:
      - 80:8080
    environment:
      - PORT=8080
      - DB_CLIENT=pg
      - DB_HOST=localhost
      - DB_PORT=5432
      - DB_DATABASE=my_own_app
      - DB_USERNAME=postgres
      - DB_PASSWORD=password
    depends_on:
      - db
  db:
    image: postgres:13-alpine
    container_name: db
    ports:
      - 5432:5432
    environment:
      - POSTGRES_DB=my_own_app
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=password

## If using mysql
#  db:
#    image: mysql:latest
#    container_name: db
#    ports:
#      - 3306:3306
#    environment:
#       MYSQL_ROOT_PASSWORD: root_password
#       MYSQL_DATABASE: my_own_app
#       MYSQL_USER: wordpress
#       MYSQL_PASSWORD: password

# For MongoDB, there are further requirements that cannot be covered here

Note that we're dealing with each main component as a service e.g. our app, and the database.

version: The version of docker-compose you intend to use. You can always check for the latest
services: The dictionary of microservices you need for your fully running application. In this example, we only need our app, and a database.
build: This indicates that we are building an image for our own application from our Dockerfile. It takes the value of the root directory of the app we intend to build, which is where the Dockerfile should be.
image: We indicate the name and tag of the image we intend to use for our app in this format [registry.username/]<name>:<tag>.
ports: The list of ports mappings to the service. This indicates the port we intend to expose to the outside world in order to have access to the internal running port of the services.
The syntax reads <external port>:<internal port>.
environment: The list of environment variables for the associated service.
container_name: The default name we intend to give the container we spin-off from the built image.
depends_on: The list of microservices that the particular microservice depends on.

In the advent where your server size is to small to handle your RDBMS, use an AWS RDS (Relational Database Service) instead.

Connecting To RDS

First of all, you will need your server to be authenticated with the RDS

$ aws rds generate-db-auth-token \
   --hostname <name>.<id>.<region>.rds.amazonaws.com \
   --port 3306 \
   --region <region> \
   --username <username>

Connect to a DB instance on the RDS. The access parameters to the DB will be the env for DB connection on your own app. That is:

DB_Host=...rds.amazonaws.com
DB_NAME=
DB_PORT=
DB_USERNAME=
DB_PASSWORD=

Running The Containers

On your CLI, still at your app's root directory, run:

$ docker-compose up

In case your image is hosted on a registry e.g. AWS ECR, you will need to have access to it on your server before you can successfully run the docker-compose. To do that:

Install AWS-CLI
Login to the ECR (Elastic Container Registry). Simply run:

$ aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <registry>

You will be requested to provide certain credentials, which you should find on your AWS dashboard/profile:

AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_DEFAULT_REGION

Proxy Networking

Create and/or open the file for your site, contained in the sites available to your NGINX

$ sudo nano /etc/nginx/conf.d/sites-available/<your_domain_name>

Now in the file, edit its content to something similar.

// /etc/nginx/conf.d/sites-available/<your_domain_name>

server {
        listen 80;
        listen [::]:80;

        server_name <your_domain> [www.<your_domain>];

        location / {
                proxy_pass  http://<your_service>;
                try_files $uri $uri/ =404;
        }
}

After successfully editing and saving the file, create a sites-enabled folder if it doesn't exist. This folder will contain sites enabled for access via the NGINX.

Afterwards, symbolically link the sites-available to the sites-enabled. This will cause automatic updates from the sites available to the sites enabled.

$ cd /etc/nginx/conf.d
mkdir sites-enabled && cd sites-enabled
$ ln -s ../sites-available/plex.conf .

Change the NGINX sites lookup reference to the sites-enabled.

$ sudo nano /etc/nginx/nginx.conf

Change the line include /etc/nginx/conf.d/*.conf; to include /etc/nginx/conf.d/sites-enabled/*.conf;

When all is successfully setup, restart the NGINX.

$ sudo service nginx restart

Now, you should be able to access the service you just created on your browser, or on your terminal with an http agent e.g. curl, or Postman.

Conclusion

Hopefully this tutorial is helpful. Please leave your comments below. Feedback and more insights are very much welcome.

DEV Community: Tobi Akanji

Add New User to EC2 Linux Instance with Google MFA: Ubuntu

Get Key Pair for The New User Account

Create New User

Make User A Superuser

Update The Superuser to Not Use Password

Implement SSH Authentication

Implement Google Auth MFA

Test Connection and Privileges

Conclusion

References

Three (3) NodeJS Lessons I Have Learned In 2021

1. Pass In Required Variables Directly In An Object

2. Never Pass Undefined Value To Knex where Function

Where Clauses

3. Log Errors/Exceptions With Directives Included

Conclusion

Build and Host Containerized Micro-Services

Connecting To Your Server Via SSH

Tools

Docker

Docker Compose

NGINX

Containerizing Your Microservices

Setting Up The Dockerfile

Building The Image

Forking The Image For A Remote Docker Repo

Pushing to Docker Hub

Setting Up The Docker Compose

Connecting To RDS

Running The Containers

Proxy Networking

Conclusion

2. Never Pass Undefined Value To Knex `where` Function