Introduction
While serverless and containers are the sparkling goals of AWS, EC2 is still the sturdy workhorse in many places. One of the reasons for this is the versatility of having an operating system to do what you will. The question then becomes, how do you access that operating system? It was the standard SSH or RDP for the longest time, but AWS has released some other methods over the last few years. This blog will have a look at these and access requirements.
SSH/RDP
The old faithful and probably most versatile is the traditional SSH (for *nix) or RDP (for Windows) connection. The connectivity is the same as with on-prem, VMware, Hyper-V, whatever. There are some slight differences with AWS, though.
Firstly, you’ll need to have a security group that allows access to 22 (SSH), 3389 (RDP), or both. Then you need to enable that ingress traffic from somewhere. Do your servers have direct inbound access from the internet (DON’T DO THIS WITHOUT A GOOD REASON)? Do you have direct connectivity from your corporate network, or maybe an Amazon Workspace?
The next thing you’ll need is a PEM key. The PEM key has a different use whether you are connecting to Linux or Windows instances. For Windows, this decodes the default Administrator password. Once you change the Administrator password, this no longer works. For SSH, the PEM file is used to access the default user without revealing a password.
Once access is configured, and the PEM key is available, it’s just a standard SSH or RDP connection.
Note1: For SSH access via Linux or macOS, set the PEM key permission to 400.
Note2: There are options on boot to configure users, join Windows domains, etc. This, and the following, sections are just assuming a basic configuration.
SESSION manager
The next access method I’ll cover has been around since Sep 2018 but has had mixed exposure. Some people love it, and others haven’t heard of it. A recent update to the EC2 console has made it a lot more visible, though. I am talking about Session Manager.
Previously, AWS “hid” Session Manager within the Systems Manager (SSM) console. As a result, a lot of people didn’t know Session Manager existed. Great, but what is it? Well, Session Manager is a browser-based interactive shell connection to your EC2 instances. For Windows servers, this is a PowerShell connection. For Linux, this defaults to bash. The user for both is ssm-user.
Great! So, I can just jump straight in and use it? Well, no. There is a bit of configuration needed. Firstly, the SSM Agent needs installing. The agent is pre-installed on Amazon Linux, Amazon Linux2, Ubuntu, Windows & macOS instances. For other Linux versions, including Red Hat Enterprise Linux, this needs to be manually installed. Secondly, the instance needs to have appropriate permissions to access the SSM services. Configuring authorisation is generally done by ensuring the instances have an attached role with at least the AmazonSSMManagedInstanceCore policy. Finally, the instance needs to talk to the SSM services via internet connection or VPC endpoints. For security reasons, VPC endpoints are my preference. If using that method, the endpoints needed are ssm, ssmmessages, and ec2messages.
Full configuration details are here: https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html
I won’t go into detail here, but there are many benefits to using Session Manager, including session logging, using policies for restricting access, etc. There were a lot of updates to Session Manager functionality in 2019 and 2020. Session Manager is worth a look. At a minimum, enabling the SSM agent allows management via all the SSM tools.
EC2 Serial console
We now get to the new kid on the block, as far as EC2 access goes, EC2 Serial Console. The EC2 Serial Console was released in March 2021. It’s available on both Windows and Linux instances but seems better suited to Linux. As the name suggests, this is giving the equivalent of COM1 access to the instance. I’ve had a little play with both Windows and Linux instances. I could see some of the boot messages with the Windows instances but didn’t get a login. For Linux, it was effortless, and I got a login straight away.
Wow! That sounds simple. I don’t need any Security Groups or any particular roles, just click the link, and I get a login. Awesome! Oh wait, do I have any local users? And there’s the catch. While you can SSH via ec2-user with the PEM Key or ssm-user via Session Manager, unless you have a local user (or you’re connected to a directory server), you can’t log in. One easy way to get around this is to set the root password once the server is running. I’ll cover this at the end.
EC2 Serial Console User Guide (Linux): https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-serial-console.html
EC2 Serial Console User Guide (Windows): https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-serial-console.html
aws cloudshell
This one is not a direct access method, but it sort of ties in, is new and interesting, so what the hell. AWS CloudShell was announced in Dec 2020 and released in Sydney in April 2021. AWS describes CloudShell as “a browser-based, pre-authenticated shell that you can launch directly from the AWS Management Console.” It runs an Amazon Linux 2 based environment with a pre-installed set of dev tools, AWS CLI, and 1GB of persistent storage (for free). It also has git-remote-codecommit installed for working directly with AWS CodeCommit.
I’ve only played around with this a little bit, but I can see the potential. From consultants who want to keep customer access off their devices to support staff having access to pretty much everything they need just via a browser. It will be fascinating to watch this service and see what happens. Lots of AWS services start as barely usable and then get better over time. This service already comes configured with most of what you need.
Note: It does take a short while to spin up the environment.
AWS CloudShell User Guide: https://docs.aws.amazon.com/cloudshell/latest/userguide/welcome.html
changing root password
I mentioned in the section on EC2 Serial Console that it would be a good idea to change the root password. You can do this manually, but it can be difficult for a large fleet of servers. By configuring your instances with the SSM Agent, you not only get access via Session Manager, but you can also use RunCommands and State Manager to perform tasks in bulk. I’ve written a little RunCommand document that pulls a secure string Parameter Store item to set the root password. You could have different entries for different environments and use State Manager to run this for password rotation regularly. Why is it good to know the root password if you have sudo access via ec2-user or ssm-user? Well, one time, I was testing out some changes to the sudoers file via a RunCommand. It didn’t format as expected, and I wasn’t able to use sudo. Thankfully I was on a test box I ran up just for that reason, but without knowing the root password, all I could do was blow it away and start again (well, there are other ways, but it was a test box).
SSM Document (YAML):
—
schemaVersion: “2.2”
description: “Change Root Password”
mainSteps:
– action: “aws:runShellScript”
name: “root_password_change”
inputs:
runCommand:
– “#This updates the root password using a Parameter Store secure string”
– “value=$(aws ssm get-parameters –names /Parameter/Name –with-decryption –region ap-southeast-2 –output text –query Parameters[].Value)”
– “echo $value | passwd root –stdin”
summary
This blog highlighted three ways to connect to your EC2 instance (SSH/RDP, Session Manager, and EC2 Serial Console) and introduced the AWS CloudShell. The easiest to configure is the EC2 Serial Console, but that’s more designed for emergencies. While Sessions Manager requires the most configuration, this is the one people should be using. It has a lot more benefits than just connectivity and a lot more flexibility in the connectivity. Finally, I introduced AWS CloudShell. It looks exciting and worth a play.
