Skip to content

AWS SSM and How We Can Use It To SSH Into EC2 Instances

Background

EC2

Stands for “Elastic Compute 2,” the service AWS offers. An EC2 instance is a virtual server operating within AWS’ cloud infrastructure (which we task to handle our compute).

SSH

Stands for “Secure Shell.” It’s the cryptographic network we use to connect to our EC2 instances. It allows for secure connection over an unsecure network. Read more.

  • How we currently log (SSH) into our EC2 instances
    1. SSO in to AWS
    2. Turn on our EC2 instance
    3. Wait for the instance to load
    4. Copy the public IPV4 address
    5. Access our terminal
    6. Open our SSH configuration
    7. Paste the IPV4 address next to HostName
    8. Log into our accounts

This is obviously time-consuming and inefficient. SSM offers a simplified approach to SSH-ing into our EC2 instances.

SSM

Stands for “System Service Manager,” and is a bundled suite of tools for managing our cloud infrastructure. Especially helpful to us, SSM allows us to manage our EC2 instances with ease, with one tool in particular: Session Manager.

Session Manager

- One-click access to managed nodes from the console and CLI (works cross-platform) 
This means no more SSH keys each time we want to access a node!

Session Manager also includes AWS CLI (command line interface) which allows us to begin, view, and end sessions.

AWS PrivateLink

- Managing nodes without public IPv4 addresses

    As you may remember, our current method of accessing and activating EC2 instances requires pasting the IPV4 address into our SSH configuration within the terminal. Wouldn’t it be better if our EC2 instance could connect privately, circumventing a public IPV4 address? In comes AWS PrivateLink!

Setting up AWS Systems Manager

Steps:

  • Prerequisites to SSM

    1. Create an AWS account (as a root user) and configure the required AWS Identity and Access Management (IAM) for other users.

      • Read more

        Root User

        The user who creates the AWS account. They act as an administrator and have access to every tool/resource in their AWS account. The root user can (and is supposed to) create users in Identity and Access Management within their account with specific credentials.

    2. Verify that your machines run a supported operating system.

    3. For edge devices, verify that your devices are configured to run the AWS IoT Greengrass Core software. For edge devices that don't run AWS IoT Greengrass Core software, the machines must be configured as on-premises machines for Systems Manager.
    4. For Amazon EC2 instances, create an IAM instance profile and attach it to your machines.
    5. For on-premises servers, edge devices, and VMs, create an IAM service role.

    6. (Recommended) Create a VPC endpoint in Amazon Virtual Private Cloud (Amazon VPC) to use with Systems Manager. This step is particularly useful when we use AWS PrivateLink, which requires that we have VPC endpoints.

      If you don't use a VPC endpoint, configure your managed instances to allow HTTPS (port 443) outbound traffic to the Systems Manager endpoints. For information, see (Recommended) Create a VPC endpoint.

    7. For on-premises servers, edge devices, VMs, and Amazon EC2 instances created from Amazon Machine Images (AMIs) that aren't supplied by AWS, ensure that a Transport Layer Security (TLS) certificate is installed.

    8. For on-premises servers and VMs, register the machines with Systems Manager through the managed instance activation process.
    9. Install or verify installation of the SSM Agent on each of your managed nodes.
    10. For Amazon EC2 instances, verify the instance can reach the Instance Metadata Service (IMDS). Systems Manager relies on EC2 instance metadata to function correctly.

    This text was sourced from here.

Initializing hybrid environments (installing SSM agent)

Initializing edge devices

Installing Session Manager (learn how to use Session Manager here)

This article focused primarily on AWS Session Manager, a tool within AWS SSM. To see other tools which may complement SSM or Session Manager in particular, see under the “Node management” heading here.