DEV Community: Paul Micheli

DevOps Study Roadmap

Paul Micheli — Mon, 02 Aug 2021 09:05:16 +0000

1. Learning a programming language

You need to get a good grasp of a programming language. It doesn't matter which one, but it's needed for writing automation code. Automation is a key part of DevOps. You can learn Python, Java, Ruby, Golang etc.

2. Understand different OS concepts

As suggested in the roadmap, you need to learn about process management, threads & concurrency, sockets, I/O management, virtualization, memory system, etc.

3. Learn to Live in terminal

Terminal commands are essential for a DevOps engineer, especially if you are working on linux. You need to learn commands for process monitoring, text manipulation, system performance, etc. When you practice these commands, you can become a master at shell scripting.

4. Network, Security & Protocols

You need to be familiar with various types of protocols which play a major role in communicating with different devices across the network like TCP/IP, HTTP, HTTPS, SMTP, FTP etc.

5. What is and how to setup

In general, a DevOps engineer should know how to set up a web server like IIS, Nginx, Apache and Tomcat. They should also know about Caching Server, Load balancer, Reverse Proxy, and Firewall, etc.

6. Learn Infrastructure as code

This is one of the most critical component in the learning path of a DevOps engineer. You need to learn about app containerization and have thorough understand of container tools like Docker and Kubernetes. Infrastructure provisioning tools such as Cloudformation, CDK, Terrafor,. Configuration management tools like Ansible, Chef, Salt & Puppet. Other areas include container orchestration and infrastructure provisioning.

7. Learn some Continuous Integration and Delivery (CI/CD) tools

Continuous Integration/Continuous Deployment is now a core part of setting a DevOps culture. So you should get familiar with CI/CD tools like Jenkins, Github actions etc.

8. Learn to monitor software and infrastructure

When you have thousands of services running, it's important to make sure that the system is running in fine health. Both your infrastructure and application should be continuously monitored.

9. Learn about Cloud Providers

Most of the apps today are built as cloud-native. So you need to make yourself familiar with major cloud providers. AWS, Azure and Google Cloud are the leading players.

SSH Key Best Practices

Paul Micheli — Thu, 22 Apr 2021 11:00:52 +0000

Ensure Separation

Ensure SSH Keys Are Associated With a Single Services

Tie SSH keys back to an individual services, rather than just a generic key that is associated with multiple services github / acquia /aws etc . This will provide an effective SSH audit trail and more direct oversight.

Use a separate key per client you SSH from

So don’t copy the private key from your laptop to another laptop for use in parallel. Each client system should have only one key, so in case a key leaks, you know which client system was compromised. If you stop using your old laptop and start using a new one it is naturally another case and then you can copy the key.

Comments

Adding comments to keys can allow you to organize your keys more easily. The comments are stored in end of the public key file and can be viewed in clear text. For example:

cat ~/.ssh/{keyservice}_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQDG..........qiaWxRUdk0UKU0c5ZqQYHRCw== username@hostname

Choose different SSH algorithm

Once a key pair is generated, its algorithm cannot be changed. So you need to be careful about the algorithm. Some of the options are as below:

RSA – Default and most popular algorithm. It is based on the difficulty of factoring large numbers. A key size of at least 4096 bits is recommended for RSA. RSA is getting old and significant advances are being made in factoring. Choosing a different algorithm is advisable where possible.
DSA – An old US government Digital Signature Algorithm. It is based on the difficulty of computing discrete logarithms. A key size of 1024 would normally be used with it. DSA in its original form is no longer recommended.
ECDSA – A new Digital Signature Algorithm standardized by the US government, using elliptic curves. This is the recommended algorithm for current applications/service if supported. Only three key sizes are supported: 256, 384, and 521 (sic!) bits. Most SSH clients now support this algorithm.
ED25519 – This is one of the new algorithms added in OpenSSH. Support for it in clients is not yet universal. You need to check the documentation of the SSH clients and servers, if they support this algorithm.

Key Generation

NOTE: Only use RSA if it is the only option for the service offers, follow "Choose different SSH algorithm"

The algorithm is selected using the -t option and key size using the -b option.

If you do not want the ssh-keygen to prompt you for the filename, you can supply it using -f option.

To add a comment to the public key file when generating the key add to the key generation command -C "username@hostname". The following commands illustrate:

ssh-keygen -t rsa -b 4096 -f ~/.ssh/github_rsa -C "username@hostname"

ssh-keygen -t dsa -f ~/.ssh/github_dsa -C "username@hostname"

ssh-keygen -t ecdsa -b 521 -f ~/.ssh/github_rsa -C "username@hostname"

ssh-keygen -t ed25519 -f ~/.ssh/github_ed -C "username@hostname"

Stay vigilant

If running ssh remote.example.com yields some error messages, don’t ignore them! SSH has an opportunistic key model, which is convenient, but it also means that if you are confronted with warnings that the connection might be eavesdropped you should really take note and not proceed.

Simplify Your Life With an SSH Config File

Paul Micheli — Thu, 22 Apr 2021 10:53:47 +0000

If you're anything like me, you probably log in and out of a half dozen remote servers (or these days, local virtual machines) on a daily basis. And if you're even more like me, you have trouble remembering all of the various usernames, remote addresses and command line options for things like specifying a non-standard connection port or forwarding local ports to the remote machine.

Shell Aliases

Let's say that you have a remote server named dev.example.com, which has not been set up with public/private keys for password-less logins. The username to the remote account is fooey, and to reduce the number of scripted login attempts, you've decided to change the default SSH port to 2200 from the normal default of 22. This means that a typical command would look like:

$ ssh paulmicheli@dev.example.com -p 22000

password: *************

Not too bad.

We can make things simpler and more secure by using a public/private key pair; I highly recommend using ssh-copy-id for moving your public keys around. It will save you quite a few folder/file permission headaches.

$ ssh paulmicheli@dev.example.com -p 22000

Assuming your keys are properly setup…

Now this doesn't seem all that bad. To cut down on the verbosity you could create a simple alias in your shell as well:

$ alias dev='ssh paulmicheli@dev.example.com -p 22000'
$ dev # To connect

This works surprisingly well: Every new server you need to connect to, just add an alias to your .bashrc (or .zshrc if you hang with the cool kids), and voilà.

~/.ssh/config

However, there's a much more elegant and flexible solution to this problem. Enter the SSH config file:

# contents of $HOME/.ssh/config

Host dev
    HostName dev.example.com
    Port 22000
    User paulmicheli

This means that I can simply $ ssh dev, and the options will be read from the configuration file. Easy peasy. Let's see what else we can do with just a few simple configuration directives.

Personally, I use quite a few public/private keypairs for the various servers and services that I use, to ensure that in the event of having one of my keys compromised the damage is as restricted as possible. For example, I have a key that I use uniquely for my Github account. Let's set it up so that that particular private key is used for all my github-related operations:

Host dev
    HostName dev.example.com
    Port 22000
    User paulmicheli

Host github.com
    IdentityFile ~/.ssh/github_ecdsa

Host prod.ssh.hostingservice.com
    user user.prod
    IdentityFile ~/.ssh/hosting_service_rsa

Host dev.ssh.hostingservice.com
    user user.dev
    IdentityFile ~/.ssh/hosting_service_rsa

The use of IdentityFile allows me to specify exactly which private key I wish to use for authentification with the given host. You can, of course, simply specify this as a command line option for "normal" connections:

$ ssh -i ~/.ssh/blah.key username@host.com

but the use of a config file with IdentityFile is pretty much your only option if you want to specify which identity to use for any git commands. This also opens up the very interesting concept of further segmenting your github keys on something like a per-project or per-organization basis:

Host github-project1
    User git
    HostName github.com
    IdentityFile ~/.ssh/github.project1.key

Host github-org
    User git
    HostName github.com
    IdentityFile ~/.ssh/github_ecdsa

Host github.com
    User git
    IdentityFile ~/.ssh/github.key

Which means that if I want to clone a repository using my organization credentials, I would use the following:

$ git clone git@github-org:orgname/some_repository.git

Improving My DBA Skill-Set

Paul Micheli — Wed, 30 Sep 2020 10:30:21 +0000

I want to improve my DBA skill-set and wanted to reach out to the community to point me in a good direction, Mainly starting with Relational Databases.

Where is best to start?

Upgrade AWS Elastic Beanstalk PHP Major version

Paul Micheli — Mon, 28 Sep 2020 11:11:16 +0000

The AWS Elastic Beanstalk Console currently allows you to change between minor platform versions ( e.g. 64bit Amazon Linux 2018.03 v2.9.10 running PHP 7.1 to64bit Amazon Linux 2018.03 v3.1.10 running PHP 7.1), but doesn’t support changes between major versions (e.g. 64bit Amazon Linux 2018.03 v2.9.10 running PHP 7.1 to 64bit Amazon Linux 2 v3.1.1 running PHP 7.3).

But is it possible to update to a major platform version using the AWS Command Line Interface (CLI):

You will need to get the EnviromentID of the beanstalk environment using the below command;

paulmicheli@minime:~$ aws elasticbeanstalk describe-environments --environment-names APP1

You will get the EnvironmentID from the out;

{
    "Environments": [
        {
            "EnvironmentName": "APP1",
            "EnvironmentId": "e-***********4",
            "ApplicationName": "Application 1",
            "VersionLabel": "app_1_branch-28-09-2020",
            "SolutionStackName": "64bit Amazon Linux 2018.03 v2.9.10 running PHP 7.1",
            "PlatformArn": "arn:aws:elasticbeanstalk:us-east-1::platform/PHP 7.1 running on 64bit Amazon Linux/2.9.10",
            "Description": "PHP 7.1 env",
            "EndpointURL": "app1.elb.amazonaws.com",
            "CNAME": "app1.elb.amazonaws.com",
            "DateCreated": "2019-05-15T10:44:17.800000+00:00",
            "DateUpdated": "2020-09-25T13:01:05.997000+00:00",
            "Status": "Ready",
            "AbortableOperationInProgress": false,
            "Health": "Green",
            "HealthStatus": "Ok",
            "Tier": {
                "Name": "WebServer",
                "Type": "Standard",
                "Version": "1.0"
            },
            "EnvironmentLinks": [],
            "EnvironmentArn": "arn:aws:elasticbeanstalk:us-east-1:123456789101:environment/Application 1/APP1"
        }
    ]
}

You will need to provide the --solution-stack-name these can be found by running this command;

paulmicheli@minime:~$ aws elasticbeanstalk list-available-solution-stacks

Once you have the Environment ID you can run the below command,

paulmicheli@minime:~$ aws elasticbeanstalk update-environment --solution-stack-name "64bit Amazon Linux 2 v3.1.1 running PHP 7.3" --environment-id "e-***********4"

The out put of the command will state the old PlatformArn, this will update once the Environment has updated;

{
    "EnvironmentName": "APP1",
    "EnvironmentId": "e-***********4",
    "ApplicationName": "Application 1",
    "VersionLabel": "app_1_branch-28-09-2020",
    "SolutionStackName": "64bit Amazon Linux 2018.03 v2.9.10 running PHP 7.1",
    "PlatformArn": "arn:aws:elasticbeanstalk:us-east-1::platform/PHP 7.1 running on 64bit Amazon Linux/2.9.10",
    "Description": "PHP 7.1 env",
    "EndpointURL": "app1.elb.amazonaws.com",
    "CNAME": "app1.elb.amazonaws.com",
    "DateCreated": "2019-05-15T10:44:17.800000+00:00",
    "DateUpdated": "2020-09-25T13:29:34.420000+00:00",
    "Status": "Updating",
    "AbortableOperationInProgress": true,
    "Health": "Grey",
    "Tier": {
        "Name": "WebServer",
        "Type": "Standard",
        "Version": "1.0"
    },
    "EnvironmentArn": "arn:aws:elasticbeanstalk:us-east-1:123456789101:environment/Application 1/APP1"
}

Rerun the below command and the PlatformARN will update once the update has completed;

paulmicheli@minime:~$ aws elasticbeanstalk describe-environments --environment-names APP1
{
    "Environments": [
        {
            "EnvironmentName": "APP1",
            "EnvironmentId": "e-***********4",
            "ApplicationName": "Application 1",
            "VersionLabel": "app_1_branch-28-09-2020",
            "SolutionStackName": "64bit Amazon Linux 2 v3.1.1 running PHP 7.3",
            "PlatformArn": "arn:aws:elasticbeanstalk:us-east-1::platform/PHP 7.3 running on 64bit Amazon Linux 2/3.1.1",
            "Description": "PHP 7.1 env",
            "EndpointURL": "app1.elb.amazonaws.com",
            "CNAME": "app1.elb.amazonaws.com",
            "DateCreated": "2019-05-15T10:44:17.800000+00:00",
            "DateUpdated": "2020-09-25T13:30:58.881000+00:00",
            "Status": "Ready",
            "AbortableOperationInProgress": false,
            "Health": "Green",
            "HealthStatus": "Ok",
            "Tier": {
                "Name": "WebServer",
                "Type": "Standard",
                "Version": "1.0"
            },
            "EnvironmentLinks": [],
            "EnvironmentArn": "arn:aws:elasticbeanstalk:us-east-1:123456789101:environment/Application 1/APP1"
        }
    ]
}

Terraform Discussion

Paul Micheli — Sun, 20 Sep 2020 15:56:20 +0000

How agnostic is Terraform?

I am heavily AWS focused in my role, and use Cloudformation for my Infrastructure as code.

Most DevOps Engineers I talk to are confused why I use Cloudformation over Terraform as Terraform is cloud-agnostic, they are of the opinion I should be using Terraform as I can then point to a new cloud provider and click, and POOF! your stack has appeared.

Terraform use cases

Multi-Cloud Deployment

It's often attractive to spread infrastructure across multiple clouds to increase fault-tolerance. By using only a single region or cloud provider, fault tolerance is limited by the availability of that provider. Having a multi-cloud deployment allows for more graceful recovery of the loss of a region or entire provider.

Realizing multi-cloud deployments can be very challenging as many existing tools for infrastructure management are cloud-specific. Terraform is cloud-agnostic and allows a single configuration to be used to manage multiple providers, and to even handle cross-cloud dependencies. This simplifies management and orchestration, helping operators build large-scale multi-cloud infrastructures.

How agnostic is Terraform? How much work is needed to deploy a stack with some compute, network & Storage from one cloud provider to another? How true is the above statement? One file point to AWS, Azure, Google and it builds?

AWS Automated Snapshot Cloudformation

Paul Micheli — Sat, 19 Sep 2020 13:17:12 +0000

I recently had the pleasure of overhauling the snapshot tool we have across our AWS accounts, the account was inherited from a previous admin who had configured the snapshot tooling before AWS introduced there Data Lifecycle Manager

With Amazon Data Lifecycle Manager, you can manage the lifecycle of your AWS resources. You create lifecycle policies, which are used to automate operations on the specified resources.
Amazon DLM supports Amazon EBS volumes and snapshots. For information about using Amazon DLM with Amazon EBS.

As we like to make sure we have every thing done as infrastructure as code, the below cloudformation template will create 4 policies for multiple retention period options, 5, 30, 60, 90 days.(you can change this to fit your needs)

AWSTemplateFormatVersion: 2010-09-09
Description: >-
  Amazon Data Lifecycle Manager to automate the creation, retention, and deletion of snapshots taken to back up your Amazon EBS volumes
#Metadata: 


Resources:
  dlmRole:
    Type: AWS::IAM::Role
    Properties:
      Path: /service-role/dlm/
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
        -
          Effect: "Allow"
          Action:
          - sts:AssumeRole
          Principal:
            Service:
            - dlm.amazonaws.com
      Policies:
      - PolicyName: "dlmPolicy"
        PolicyDocument:
          Version: '2012-10-17'
          Statement:
          - Effect: Allow
            Action:
            - ec2:CreateSnapshot
            - ec2:CreateSnapshots
            - ec2:DeleteSnapshot
            - ec2:DescribeVolumes
            - ec2:DescribeInstances
            - ec2:DescribeSnapshots
            Resource: "*"
          - Effect: Allow
            Action:
            - ec2:CreateTags
            Resource: arn:aws:ec2:*::snapshot/*

  dlmLifecyclePolicy:
    Type: "AWS::DLM::LifecyclePolicy"
    Properties:
      Description: "DevOps Lifecycle Policy using CloudFormation 5 Day Retention"
      State: "ENABLED"
      ExecutionRoleArn: !GetAtt dlmRole.Arn
      PolicyDetails:
        ResourceTypes:
          - "INSTANCE"
        TargetTags:
          -
            Key: "DLM-BACKUP"
            Value: "YES"

        Schedules:
          -
            Name: "Daily Snapshots 5 Day Retention"
            TagsToAdd:
              -
                Key: "type"
                Value: "DailySnapshot"

            CreateRule:
              Interval: 24
              IntervalUnit: "HOURS"
              # UTC The time at which the policy runs are scheduled to start. The first policy run starts within an hour after the scheduled time. 
              Times:
                - "02:10"
            RetainRule:
              Count: 5
            CopyTags: true

  dlm30LifecyclePolicy:
    Type: "AWS::DLM::LifecyclePolicy"
    Properties:
      Description: "DevOps Lifecycle Policy using CloudFormation 30 Day Retention"
      State: "ENABLED"
      ExecutionRoleArn: !GetAtt dlmRole.Arn
      PolicyDetails:
        ResourceTypes:
          - "INSTANCE"
        TargetTags:
          -
            Key: "DLM-30BACKUP"
            Value: "YES"

        Schedules:
          -
            Name: "Daily Snapshots 30 Day Retention"
            TagsToAdd:
              -
                Key: "type"
                Value: "DailySnapshot"

            CreateRule:
              Interval: 24
              IntervalUnit: "HOURS"
              # UTC The time at which the policy runs are scheduled to start. The first policy run starts within an hour after the scheduled time. 
              Times:
                - "02:10"
            RetainRule:
              Count: 30
            CopyTags: true

  dlm60LifecyclePolicy:
    Type: "AWS::DLM::LifecyclePolicy"
    Properties:
      Description: "DevOps Lifecycle Policy using CloudFormation 60 Day Retention"
      State: "ENABLED"
      ExecutionRoleArn: !GetAtt dlmRole.Arn
      PolicyDetails:
        ResourceTypes:
          - "INSTANCE"
        TargetTags:
          -
            Key: "DLM-60BACKUP"
            Value: "YES"

        Schedules:
          -
            Name: "Daily Snapshots 60 Day Retention"
            TagsToAdd:
              -
                Key: "type"
                Value: "DailySnapshot"

            CreateRule:
              Interval: 24
              IntervalUnit: "HOURS"
              # UTC The time at which the policy runs are scheduled to start. The first policy run starts within an hour after the scheduled time. 
              Times:
                - "02:10"
            RetainRule:
              Count: 60
            CopyTags: true

  dlm90LifecyclePolicy:
    Type: "AWS::DLM::LifecyclePolicy"
    Properties:
      Description: "DevOps Lifecycle Policy using CloudFormation 90 Day Retention"
      State: "ENABLED"
      ExecutionRoleArn: !GetAtt dlmRole.Arn
      PolicyDetails:
        ResourceTypes:
          - "INSTANCE"
        TargetTags:
          -
            Key: "DLM-90BACKUP"
            Value: "YES"

        Schedules:
          -
            Name: "Daily Snapshots 90 Day Retention"
            TagsToAdd:
              -
                Key: "type"
                Value: "DailySnapshot"

            CreateRule:
              Interval: 24
              IntervalUnit: "HOURS"
              # UTC The time at which the policy runs are scheduled to start. The first policy run starts within an hour after the scheduled time. 
              Times:
                - "02:10"
            RetainRule:
              Count: 90
            CopyTags: true

Once the stack has been deployed you can tag the instance you would like to automate your snapshot's with the relevant tag's (case sensitive), I did notice on the first run of each policy there is a couple hours of delay until you start to see the creation of your snapshots, this corrects its self on the second run

EC2 Tagging MKII

Paul Micheli — Mon, 14 Sep 2020 15:27:01 +0000

A few weeks ago I posted about a crude bash script to tag your EC2 resources, I have since tweaked the script to use the instance ID to find the volumes and snapshots associated with each instance ID.

It will also dynamically pull in account to use from your AWS config file.

Have Fun

#!/bin/bash

## Functions

tag_rescources () {
aws --profile=$profile --region=$region ec2 create-tags --resources $1 \
    --tags Key="COST CENTRE",Value="$cost" \
      Key="APP",Value="$app" \
      Key="ENVIRONMENT",Value="$environment" \
      Key="OWNER",Value="$owner" 
}

get_volumes (){
aws --profile=$profile --region=$region ec2 describe-volumes \
  --filters Name=attachment.instance-id,Values=$1 \
  --query "Volumes[].VolumeId" --output=text
}

get_snapshots(){
aws --profile=$profile --region=$region ec2 describe-snapshots \
  --filters Name=volume-id,Values=$1 \
  --query "Snapshots[].SnapshotId" --output=text
}


## Script
echo "Use this script to tag EC2 instance in the desired account"
echo "Multiple can be enter at once seperated by a singe space."
echo "Below resources are supported using the ID"
echo "            Instance ID"
echo "            Security Group ID"
echo "            Elastic IPs Allocation ID"
echo " "
echo "----------------------------------------------------------- "
echo "Please choose AWS Account Profile"
select profile in `grep '^\[' ~/.aws/config|sed -r 's/\[|\]//g'|awk '{print $2}'`
do
   echo "Please choose AWS Region"
   select region in eu-west-1 eu-central-1 us-east-1
   do

   echo "Please list EC2 Instance ID"
   echo "Multiple can be entered at once, seperated by a singe space."
   read instance
   echo "Please Enter COST CENTRE"
   read cost
   echo "Please Enter APP"
   read app
   echo "Please Enter ENVIRONMENT"
   read environment
   echo "Please Enter OWNER"
   read owner

   ## Tagging EC2 Instances
   for i in $instance
   do
      tag_rescources $i
      echo "Tagging EC2 Instances $i"
   done

   ## Tagging Volunmes
   #! a nested loop is used as the get volume function can only filter one volume at a time
   for i in $instance
   do
         for j in `get_volumes $i`
         do
            echo "Tagging Volume $j beloning to Instance $i"
            tag_rescources $j
         done
   done

   ## Tagging Snapshots
   #! a nested loop is used as the get snapshot function can only filter one volume at a time
   volumes=`get_volumes $instance`
   for i in $volumes
   do
         for j in `get_snapshots $i`
         do
            echo "Tagging SnapShot $j belonging to Volume $i"
            tag_rescources $j
         done
   done

   echo "If no error's above tagging complete"
   break
   done
   break
done

Using your Yubikey to store your SSH Key (RSA 4096)

Paul Micheli — Fri, 11 Sep 2020 10:29:55 +0000

Using your Yubikey to store your SSH Key (RSA 4096)

Prerequisites

For this procedure to work you must have GnuPG version 2.0.22 or later installed on your computer. The version of the YubiKey’s OpenPGP module must be 1.0.5 or later. To check this version you may run, after inserting your YubiKey:

$ gpg-connect-agent --hex "scd apdu 00 f1 00 00" /bye
D[0000]  01 00 05 90 00                               
OK

Where "01 00 05" means version 1.0.5.

If you have an existing key you want to import, that key must be a RSA 2048 bit key.

You’ll also need the YubiKey’s Admin PIN. (Default 12345678)

Generate a key

Skip this step if you already have a key.

$ gpg --gen-key

gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection?

As there are key size and type limits depending on the type of your YubiKey, see the comparison page, we will select option 1, and go with the default of 4096 bits for the next question.

RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? 4096

Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)

Select an expiry date if you want to. And answer that the data is correct.

Should be the real name associated with this key.

Should be the email adress associated with this key.

May be a comment attached to the key if you want, or leave this empty.

Real name:
Email address:
Comment:

If you’re happy with this USER-ID answer O for okay.

You selected this USER-ID:
    "Paul Micheli <paul@*********.com>m>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

Take note of the id of the key, in this case 1******5.

We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: key 13AFCE85 marked as ultimately trusted
public and secret key created and signed.

gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   4  signed:   8  trust: 0-, 0q, 0n, 0m, 0f, 4u
gpg: depth: 1  valid:   8  signed:   2  trust: 3-, 0q, 0n, 5m, 0f, 0u
gpg: next trustdb check due at 2014-03-23
pub   4***R/1******5 2020-08-11 [expires: 2024-08-11]
      Key fingerprint = 7*************************************5
uid                Paul Michei <paul@*********.com>m>

Importing the key

Now it’s time to import the key into the YubiKey as your Auth SSH Key.

$ gpg --edit-key 1******5

gpg (GnuPG) 2.0.22; Copyright (C) 2013 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Secret key is available.

pub  4***R/1******5  created: 2020-08-11 [expires: 2024-08-11]  usage: SC
                     trust: ultimate      validity: ultimate
[ultimate] (1). Paul Micheli <paul@*********.com>m>

gpg> toggle

sec  4***R/1******5  created: 2020-08-11 [expires: 2024-08-11]
(1)  Foo Bar <foo@example.com>

gpg> keytocard
Really move the primary key? (y/N) y
Signature key ....: [none]
Encryption key....: [none]
Authentication key: [none]

Please select where to store the key:
   (1) Signature key
   (3) Authentication key
Your selection? 3

Here we’ve just moved the primary key to the PGP Auth slot of the YubiKey.

gpg> key 3

sec  4096R/13AFCE85  2020-08-11 [expires: 2024-08-11]
                     card-no: 0000 00000001
(1)  Paul Micheli <paul@*********.com>m.com>

gpg> keytocard
Signature key ....: [none]
Encryption key....: [none]
Authentication key: 743A 2D58 688A 9E9E B4FC  493F 70D1 D7A8 13AF CE85

And as a last step we’ve now moved the Authentication key to the YubiKey.

gpg> quit
Save changes? (y/N) y

After this the keyring is saved. And that point it no longer contains the real secret key, only a pointer indicating that it’s stored on a smart card.

You can delete this key from your local gpg DB so it is only stored on your YubiKey.

Viewing the public key

To reveal the public key needed to add to your servers authorized_keys file so you can use the SSH key on your YubiKey to SSH to remote servers.

Run the below command to reveal the public key part of your SSH key pair;

paulmicheli@minime:~$  ssh-add -L
ssh-rsa A********************Fey
**[NOPE NOT HAVING THE MIDDLE]**
****===ZDdO cardno:0***********8

You can copy this to your authorized_keys file to your server and then test using ssh, if you use puppet to manage your SSH key deployment you can copy it there also.

Using your Yubikey for Signed Git Commits

Paul Micheli — Thu, 10 Sep 2020 06:30:39 +0000

By signing our Git commits, we can allow folks to verify that they were really written by the author tagged on the commit. If you’ve got a Yubikey set up as per our Using your Yubikey to get started with GPG Post, it’s easy to configure.

Setup

With your Yubikey inserted and unlocked, find the ID of your GPG key:

$ gpg --list-secret-keys --keyid-format LONG
/home/paulmicheli/.gnupg/pubring.kbx
------------------------------------
sec   r******/3**************E 2020-07-30 [SC] [expires: 2022-07-30]
      6***************************E
uid                 [ultimate] Paul Micheli <paul@*********.com>
ssb   r******/A***************0 2020-07-30 [E] [expires: 2022-07-30]

sec>  r******/D**************4 2020-07-30 [SC]
      3**************************************4
      Card serial no. = 0006 10300768
uid                 [ultimate] Paul Micheli <paul@*********.com>
ssb   r******/0**************8 2020-07-30 [E]

Then, get your public key so that you can tell GitHub about it. The argument here is the long ID from the above command:

$ gpg --armor --export  A**********0
-----BEGIN PGP PUBLIC KEY BLOCK-----
m[NOPE NOT HAVING THE MIDDLE]
=ZDdO
-----END PGP PUBLIC KEY BLOCK-----

Copy the above public key, including the begin and end blocks, and then add it as a new key on GitHub.

We then need to tell Git to use GPG to sign commits, and specifically this key. Use the short ID from the output of the --list-secret-keys command we ran earlier. In my example, it follows rsa3072/A97FDF705EF51C50:

$ git config --global commit.gpgsign true

$ git config --global user.signingkey A**********0

Nearly there! Let’s now restart the GPG agent:

$ gpg-connect-agent reloadagent /bye

Testing

Make a commit in any repository, and hopefully you shouldn’t see an error message.

Run git log --show-signature to check that the commit was signed:

$ git log --show-signature

commit 925fb1cae8c33c0f7f4fd6b270fc9f4cf6a8ef80 (HEAD -> master, origin/master, origin/HEAD)
gpg: Signature made Thu 30 Jul 2020 13:59:27 BST
gpg:                using RSA key 6**********************E
gpg: Good signature from "Paul Micheli <paul@*********.com>" [ultimate]
Author: Paul Micheli <paul@*********.com>
Date:   Thu Jul 30 13:59:27 2020 +0100

    signed commit test

Push

Assuming that everything has worked thus far, you can now git push and bask in the resplendent glory of a lovely “Verified” badge on GitHub:

Why Bother?

You might ask what the benefit of all this is. After all, you’re already authing to GitHub with your SSH key, right?

Your SSH key proves that you can talk to GitHub, and that you’re allowed access to the repository in question. It doesn’t prove that the commits you are pushing were really written by the flagged authors though.

It’s trivial to make a commit with a false identity:

git commit -m "implement sensible error handling" --author="Robby Bobby <robbybobby@google.com>"

You can then push this, authenticating with your SSH key (or HTTP basic credentials), which is of course totally valid.

You’ve then managed to masquerade as a colleague, presumably pushing awesome code to help them get a raise. Or, perhaps, you’ve done something nefarious. But you’d never do a thing like that, would you?

Easy EC2 Tagging

Paul Micheli — Wed, 09 Sep 2020 15:45:30 +0000

Problem

I recently had the problem of inheriting an AWS account with over 1000+ EC2 resources that had an incorrect tagging strategy.

Resolve

After the manual effort of manually sorting through all the resources, and breaking them up into the correct groups. Instead of hours going through the console and tagging each resources with 4 tags I created the below script that will prompt for the required information and then tag them correctly.

I took roughly 15 minuets to run this script a few times and tag all of my resources.

I have a multi profile aws cli configuration, this will ask what profile to use and tag the resources there, if they don't exists it will error.

Update the profile line to match the profiles in your configuration file ~/.aws/config if you don't remove the below lines;

### If you don't use AWS Profiles in the CLI this can be removed
echo "Please choose AWS Account Profile"
select profile in profile1 profile2 profile3 profile4 
do

break
done

You can change the tag keys and expand on them if you need to add more.

You can input as many resource ID's on the single line as you like, use a space to separate them.

#!/bin/bash

echo "Use this script to tag EC2 Resources in the desired account"
echo "Multiple can be enter at once separated by a singe space."
echo "Below resources are supported using the ID"
echo "            Instance ID"
echo "            Snapshot ID"
echo "            Volumes ID" 
echo "            Security Group ID"
echo "            Elastic IPs Allocation ID"
echo " "
echo "----------------------------------------------------------- "

### If you don't use AWS Profiles in the CLI this can be removed
echo "Please choose AWS Account Profile"
select profile in profile1 profile2 profile3 profile4 
do

echo "Please list EC2 resources (Multiple can be entered at once)"
read resources
echo "Please Enter Cost Centre"
read cost
echo "Please Enter application"
read app
echo "Please Enter environment"
read environment
echo "Please Enter owner"
read owner

aws --profile=$profile ec2 create-tags --resources $resources  \
    --tags Key="Cost Centre",Value="$cost" \
      Key="application",Value="$app" \
      Key="environment",Value="$environment" \
      Key="owner",Value="$owner" 

echo "If no error's above tagging complete"
break
done

On to s3 tagging now.

History Is Your Friend

Paul Micheli — Mon, 07 Sep 2020 18:26:21 +0000

Linux History Command

If you leverage and utilise the command line history, you can save a lot of time on a daily bases. You can also use it to gain a better under standing of how a newly discovered server is administrated by viewing the history of commands run.

How does it work?

Just run the command;

paulmicheli@minime:~$ history
   23  sudo apt install python3.8
   24  sudo apt update
   25  sudo apt install software-properties-common
   26  sudo add-apt-repository ppa:deadsnakes/ppa
   27  sudo apt update
   28  sudo apt upgrade
   29  sudo apt install python3.8
   30  sudo apt install python
   31  sudo apt-get install python3.6
   32  sudo reboot

A date & time stamp is always helpful

Having a time stamp of when the command was run can help im many different ways.

For this to happen you will need to add the below to your .bashrc file and reload using the source command;

## History timestamp
export HISTTIMEFORMAT="%h %d %H:%M:%S "
export HISTSIZE=50000
export HISTFILESIZE=50000

paulmicheli@minime:~$ source ~/.bashrc

Now when you run the history command you'll see the date and time;

paulmicheli@minime:~$ history
   23  Sep 07 13:52:23 sudo apt install python3.8
   24  Sep 07 13:52:23 sudo apt update
   25  Sep 07 13:52:23 sudo apt install software-properties-common
   26  Sep 07 13:52:23 sudo add-apt-repository ppa:deadsnakes/ppa
   27  Sep 07 13:52:23 sudo apt update
   28  Sep 07 13:52:23 sudo apt upgrade
   29  Sep 07 13:52:23 sudo apt install python3.8
   30  Sep 07 13:52:23 sudo apt install python
   31  Sep 07 13:52:23 sudo apt-get install python3.6

the two additional arguments I have added increase the history size

How to use it

Command	Example	Description
!n	!27	Execute nth command in history
!!	!!	Execute the previous command
blah	!ls	run the most recent command that starts with ‘blah’
!blah:p	!ls:p	print out the command that !blah would run
!*	!*	the previous command except for the last word
!$	!$	Last argument of last command
!^	!^	First argument of last command

Reverse searching

Press the ctrl key and the r key simultaneously. The below prompt will appear;

(reverse-i-search)`':

Start typing the bit of the command you remember and you will see the most recent match from your command history;

(reverse-i-search)`ocke': docker ps

press ctrl+r again to cycle through all your history that match this search term.

(reverse-i-search)`ocke': docker stop 35e0e91e92de

Removing history

There may come a time that you want to remove some or all the commands in your history file. If you want to delete a particular command,

enter history -d <line number>

To clear the entire contents of the history file, execute

history -c.

The history file is stored in a file that you can modify, as well.
Bash shell users find it in their home directory as .bash_history.