Accessing Linux instance via SSM Session Manager

Configure Linux instances to be accessed via SSM Session Manager

We will check a configuration in which an EC2 instance is accessed via SSM Session Manager.

Session Manager is a fully managed AWS Systems Manager capability that lets you manage your Amazon EC2 instances through an interactive one-click browser-based shell or through the AWS CLI. You can use Session Manager to start a session with an instance in your account. After the session is started, you can run bash commands as you would through any other connection type.

Connect to your Linux instance using Session Manager

Accessing an instance using SSM Session Manager has various advantages over the common SSH access. One of the most notable points is that it eliminates the need to open ports for remote access, and it also eliminates the need for a stepping stone server.

Leaving inbound SSH ports and remote PowerShell ports open on your managed nodes greatly increases the risk of entities running unauthorized or malicious commands on the managed nodes. Session Manager helps you improve your security posture by letting you close these inbound ports, freeing you from managing SSH keys and certificates, bastion hosts, and jump boxes.

AWS Systems Manager Session Manager

This time, we will check the following two patterns of access to the EC2 instance.

1. Access via SSH * Pattern 1
2. Access via SSM Session Manager * Pattern 2

This page is for Linux instances; for information on how to access Windows instances via Session Manager, please refer to the following page.

hogehoge

Environment

Check the following two patterns of access to EC2 instances.

1. SSH access via Internet Gateway *Pattern 1
2. access using SSM Session Manager via VPC endpoint for SSM *Pattern 2

CloudFormation template files

We will build the above configuration using CloudFormation.
The CloudFormation template is placed at the following URL

https://github.com/awstut-an-r/awstut-fa/tree/main/003

github.com

Template file points

We will cover the key points of each template file to configure this environment.

If using VPC endpoints, enable DNS functionality for the VPC

Check the parameters of the VPC.

Resources:
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock: !Ref VPCCidrBlock
      EnableDnsHostnames: true
      EnableDnsSupport: true
Code language: YAML (yaml)

When setting up a VPC endpoint, two parameters need to be set in the VPC.

If you use custom DNS domain names defined in a private hosted zone in Amazon Route 53, or use private DNS with interface VPC endpoints (AWS PrivateLink), you must set both the enableDnsHostnames and enableDnsSupport attributes to true.

DNS support for your VPC

Set the two properties to “true” according to the above.

Routing configuration comparison

Let’s check the routing-related resources.
First, check the settings for the public subnet side, that is, the EC2 instance 1 that will be accessed via SSH.

Resources:
  IGW:
    Type: AWS::EC2::InternetGateway
  
  IGWAttachment:
    Type: AWS::EC2::VPCGatewayAttachment
    Properties:
      VpcId: !Ref VPC
      InternetGatewayId: !Ref IGW

  PublicSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: !Ref CidrIp1
      VpcId: !Ref VPC
      AvailabilityZone: !Sub ${AWS::Region}${AvailabilityZone1}
      
  PublicRouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      
  RouteToInternet:
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref PublicRouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref IGW
  
  PublicSubnetRouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref PublicSubnet
      RouteTableId: !Ref PublicRouteTable
Code language: YAML (yaml)

After defining the Internet gateway, prepare a route table for the public subnet and create a default route for the gateway. The default route can be created by specifying “0.0.0.0/0” as the DestinationCidrBlock property.

Next, on the private subnet side, that is, using the SSM Session Manager, check the settings for the EC2 instance 2 that will be accessed via the VPC endpoint.

Resources:
  PrivateSubnet:
    Type: AWS::EC2::Subnet
    Properties:
      CidrBlock: !Ref CidrIp2
      VpcId: !Ref VPC
      AvailabilityZone: !Sub ${AWS::Region}${AvailabilityZone2}
Code language: YAML (yaml)

No special routing settings are required here. We will only define the subnets.

Comparison of security group settings

Check the security group settings.
First, check the security group of EC2 instance 1.

Resources:
  InstanceSecurityGroup1:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub ${Prefix}-InstanceSecurityGroup1
      GroupDescription: Allow SSH.
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: !Ref SSHPort
          ToPort: !Ref SSHPort
          CidrIp: 0.0.0.0/0
Code language: YAML (yaml)

On this side, configure the settings to allow SSH inbound traffic. This will allow you to access the instance via SSH over the Internet.

Next, check the security group of the EC2 instance 2.

Resources:
  InstanceSecurityGroup2:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub ${Prefix}-InstanceSecurityGroup2
      GroupDescription: Deny All.
      VpcId: !Ref VPC
Code language: YAML (yaml)

We will not allow certain inbound traffic here. This is because we will be doing outbound traffic from the instance side to the endpoint side, as shown in the security group for VPC endpoints below.

Finally, check the security group for the VPC endpoint.

Resources:
  EndpointSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupName: !Sub ${Prefix}-EndpointSecurityGroup
      GroupDescription: Allow HTTPS from InstanceSecurityGroup2.
      VpcId: !Ref VPC
      SecurityGroupIngress:
        - IpProtocol: tcp
          FromPort: !Ref HTTPSPort
          ToPort: !Ref HTTPSPort
          SourceSecurityGroupId: !Ref InstanceSecurityGroup2
Code language: YAML (yaml)

Allow HTTPS traffic (443/tcp) from instance 2. This is one of the requirements for creating a VPC endpoint.

The security group attached to the VPC endpoint must allow incoming connections on port 443 from the private subnet of the managed instance. If incoming connections aren’t allowed, then the managed instance can’t connect to the SSM and EC2 endpoints.

Step 6: (Optional) Create a Virtual Private Cloud endpoint

VPC endpoint configuration for SSM Session Manager

Resources:
  SSMEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PrivateDnsEnabled: true
      SecurityGroupIds:
        - !Ref EndpointSecurityGroup
      ServiceName: !Sub com.amazonaws.${AWS::Region}.ssm
      SubnetIds:
        - !Ref PrivateSubnet
      VpcEndpointType: Interface
      VpcId: !Ref VPC

  EC2MessagesEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PrivateDnsEnabled: true
      SecurityGroupIds:
        - !Ref EndpointSecurityGroup
      ServiceName: !Sub com.amazonaws.${AWS::Region}.ec2messages
      SubnetIds:
        - !Ref PrivateSubnet
      VpcEndpointType: Interface
      VpcId: !Ref VPC
        
  SSMMessagesEndpoint:
    Type: AWS::EC2::VPCEndpoint
    Properties:
      PrivateDnsEnabled: true
      SecurityGroupIds:
        - !Ref EndpointSecurityGroup
      ServiceName: !Sub com.amazonaws.${AWS::Region}.ssmmessages
      SubnetIds:
        - !Ref PrivateSubnet
      VpcEndpointType: Interface
      VpcId: !Ref VPC
Code language: YAML (yaml)

Specify “true” for the PrivateDnsEnabled property to enable private DNS. Note that this parameter is enabled by default.

Specify the security group for the VPC endpoint in the SecurityGroupIds property, and specify the service for the endpoint to be created in the ServiceName property. The following three services are required to access EC2 instances using SSM Session Manager.

・com.amazonaws.[region].ssm
・com.amazonaws.[region].ec2messages
・com.amazonaws.[region].ssmmessages

How do I create VPC endpoints so that I can use Systems Manager to manage private EC2 instances without internet access?

This time, we will use the built-in function Fn::Sub to embed the CloudFormation pseudo-parameter AWS::Region and specify the name of each service. Since we need access to three services this time, we will create a VPC endpoint for each service.

Specify a private subnet in the SubnetIds property, and specify “Interface” in the VpcEndpointType property. There are two main types of VPC endpoints: gateway type and interface type. We will use the interface type.

An interface endpoint is an elastic network interface with a private IP address from the IP address range of your subnet. It serves as an entry point for traffic destined to a service that is owned by AWS or owned by an AWS customer or partner.

VPC endpoints

The gateway type is an endpoint service that targets only DynamoDB and S3, so we will specify the interface type.

EC2 Configuration Comparison

First, check the EC2 instance 1 to be accessed via SSH.

Resources:
  Instance1:
    Type: AWS::EC2::Instance
    Properties:
      ImageId: !Ref ImageId
      InstanceType: !Ref InstanceType
      KeyName: !Ref KeyName
      NetworkInterfaces:
        - AssociatePublicIpAddress: true
          DeviceIndex: 0
          SubnetId: !Ref PublicSubnet
          GroupSet:
            - !Ref InstanceSecurityGroup1
Code language: YAML (yaml)

There are two points.

First, you need to create and specify a key pair in order to SSH into an EC2 instance. In this article, we will assume that you have created a key pair called “MyKeyPair”. For more information on creating key pairs, please refer to Creating, Viewing, and Deleting Amazon EC2 Key Pairs.

The second point is the settings related to the public address. By setting “true” to the AssociatePublicIpAddress property, a public address can be automatically assigned to the instance when it is launched. The next step is to access via the VPC endpoint.

Next, we will check the instance 2 to be accessed via the VPC endpoint.

Resources:
  Instance2:
    Type: AWS::EC2::Instance
    Properties:
      IamInstanceProfile: !Ref InstanceProfile
      ImageId: !Ref ImageId
      InstanceType: !Ref InstanceType
      NetworkInterfaces:
        - DeviceIndex: 0
          SubnetId: !Ref PrivateSubnet
          GroupSet:
            - !Ref InstanceSecurityGroup2
            
  InstanceProfile:
    Type: AWS::IAM::InstanceProfile
    Properties:
      Path: /
      Roles:
        - !Ref InstanceRole
  
  InstanceRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: 2012-10-17
        Statement:
          - Effect: Allow
            Action: sts:AssumeRole
            Principal:
              Service:
                - ec2.amazonaws.com
                - ssm.amazonaws.com
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore
Code language: YAML (yaml)

The point is to associate an IAM role with the instance and give it access rights to SSM.

If an instance profile that contains the AWS managed policy AmazonSSMManagedInstanceCore is already attached to your instances, the required permissions for Session Manager are already provided.

Step 2: Verify or create an IAM role with Session Manager permissions

Create the IAM role as described above, and attach it to instance 2 through the instance profile. In order to access the instance via SSM Session Manager, you will need to install the SSM agent in addition to the above, but Amazon Linux 2-based instances have the agent installed by default, so no additional action is required.

Architecting

Using CloudFormation, we will build this environment and check its actual behavior.

Create CloudFormation stack and check resources in stacks

Create CloudFormation stacks.
For instructions on how to run CloudFormation from the AWS CLI, please refer to the following page.

CloudFormation's nested stack

Learn how to build an environment with CloudFormation's nested stack.

awstut.com

2021.12.11

After checking the resources for each stack, the following information is available for the main resources created this time.

• ID of Instance 1: i-08ee670b7a7c1ce63
• ID of instance 2: i-0a06995e9b6eada48
• DNS name of Instance 1：ec2-13-113-95-51.ap-northeast-1.compute.amazonaws.com
• PublicSubnet ID: subnet-06d397c402ed5c23f
• PrivateSubnet ID: subnet-0303094396a6d4af4
• ID of Internet Gatekeeper: igw-0ac078662be74efc1
• ID of EC2MessagesEndpoint: vpce-0ed32ba52c8d38306
• DNS name of EC2MessagesEndpoint: ec2messages.ap-northeast-1.amazonaws.com
• ID of SSMEndpoint: vpce-06231300ba511d2ba
• DNS name of the SSMEndpoint: ssmmessages.ap-northeast-1.amazonaws.com
• ID of SSMMessagesEndpoint: vpce-0f8005d988b7fb2bf
• DNS name of SSMMessagesEndpoint: ssm.ap-northeast-1.amazonaws.com

We will also check the status of the resource creation in the AWS Managemet Console.
First, we will check the route table for the public subnet.

A default route for the Internet gateway is defined. This default route allows SSH communication over the Internet.

Next, check the route table for the private subnet.

No special route is configured here, because the VPC endpoint for SSM is an interface type and does not require any routing settings.

Now let’s check the creation status of the VPC endpoint for SSM.

We can see that all of them are configured with addresses in the private subnet (10.0.2.0/24). As you can see, since the three endpoints are interface type, they are assigned addresses in the subnet, which means that no routing configuration is required.

Operation check 1: Accessing the instance via SSH

Now that we are ready, let’s check the actual behavior.

First, let’s check how to access the instance via SSH. Run SSH on the client side.

$ ssh -i MyKeyPair.pem ec2-13-113-95-51.ap-northeast-1.compute.amazonaws.com

       __|  __|_  )
       _|  (     /   Amazon Linux 2 AMI
      ___|\___|___|

Amazon Linux 2aws.amazon.com
[ec2-user@ip-10-0-1-215 ~]$
Code language: Bash (bash)

Run SSH against the public DNS name you have just checked, specifying the private key of the key pair when you run SSH.

[ec2-user@ip-10-0-1-215 ~]$ ec2-metadata -i
instance-id: i-08ee670b7a7c1ce63
Code language: Bash (bash)

In this way, after SSH, you can freely execute commands.

Operation check 2: Accessing the instance via SSM Session Manager

Next, let’s check how to access the instance via SSM Session Manager.

We will access it from the AWS CLI.

$ aws ssm start-session \
--target i-0a06995e9b6eada48

Starting session with SessionId: root-00836994a7865c011

sh-4.2$
Code language: Bash (bash)

Specify the instance ID to be accessed for the target option.

sh-4.2$ ec2-metadata -i
instance-id: i-0a06995e9b6eada48
Code language: Bash (bash)

After accessing it in this way, you can execute any command you want.

Try to resolve the DNS name of each VPC endpoint by name.

sh-4.2$ nslookup ec2messages.ap-northeast-1.amazonaws.com
Server:		10.0.0.2
Address:	10.0.0.2#53

Non-authoritative answer:
Name:	ec2messages.ap-northeast-1.amazonaws.com
Address: 10.0.2.208


sh-4.2$ nslookup ssmmessages.ap-northeast-1.amazonaws.com
Server:		10.0.0.2
Address:	10.0.0.2#53

Non-authoritative answer:
Name:	ssmmessages.ap-northeast-1.amazonaws.com
Address: 10.0.2.147


sh-4.2$ nslookup ssm.ap-northeast-1.amazonaws.com
Server:		10.0.0.2
Address:	10.0.0.2#53

Non-authoritative answer:
Name:	ssm.ap-northeast-1.amazonaws.com
Address: 10.0.2.141

Code language: Bash (bash)

As confirmed in the AWS Management Console, the address in the private subnet was returned. Thus, the traffic for SSM communication is switched to the ENI of each VPC endpoint in the same subnet.

Summary

We have confirmed two patterns of how to access a Linux instance.
In the first, we confirmed that we can access the instance via SSH by specifying the key pair.
In the second, we confirmed that we can access the instance via SSM Session Manager.