Skip links

Improving SSH Access Management with AWS Session Manager

Secure Shell (SSH) is a network protocol based on client-server architecture that offers encrypted communication between the servers for configuration and management. It encrypts data exchanged thus making a safe, secure, and reliable way of communication. It allows two types of authentication password-based and key based. SSH allows tunnelling and port forwarding to securely access remote services on local system which are not accessible directly.

While working on a project for- AWS (Amazon Web Services) migration, we were tasked with finding a secure solution that provides SSH access to a large infrastructure on AWS in a quick and easy way. During this, we stumbled upon the Session Manager feature of AWS Systems Manager, which was a relatively new managed service offering.

This feature has helped our customers a lot on the manageability perspective by combining the authentication for our AWS Cloud with our servers’ access using AWS IAM (Identity & Access Management) and SSM.

Below we will investigate all the aspects of this feature from AWS and how it overcomes the limitations of a traditional SSH implementation on a large infrastructure that is continuously growing.

Common Traditional SSH Challenges for Large Enterprises

1. Complex User Management
To provide SSH access to servers, the administrator first needs to create a new user. Then depending on the methods allowed for remote user authentication (password, key, etc.), the credentials need to be set for the new user by the administrator. If the credentials (username/password, private key, etc.) are exposed, there is an elevated risk of compromised server access. This user creation and management method works for a smaller, more static infrastructure.

But with the ever-scaling and dynamic Cloud Infrastructure, gets time-consuming, complex, and error-prone. Although certain tools available that help eases the user management process, it still requires organizations manage the tool and its infra resources and to keep it secured since it contains sensitive information related to user access, credentials, and permissions.

2. Operational Overhead
SSH needs management of a different identity store for itself. With the start of infrastructure on the cloud, IAM services on the cloud also need to be managed for user access. This results in user management on two identity services, SSH and for Cloud. This directly increases the operational overhead for the Infrastructure Team for user management.

3. Exposed SSH Port
To allow SSH connections to a server, the port used by the SSH Service needs to be opened for outside connections. The access can be restricted from only certain IP addresses or CIDR blocks, requires configuring additional security rules on the OS (Operating System) applications or networking services for Cloud Providers or OnPrem. Any misconfiguration on any layer will make an exposed SSH port that is vulnerable to outside attacks.

4. Maintenance and Cost Overhead
The most common way to reduce SSH exposure from Public networks is by creating servers in Private networks and not allowing public access directly. To SSH to these servers either Bastion Server or VPN Service is used.

Related Blog: Why is it Better to Migrate On-Premises Data to Cloud
Learn More

Since the Bastion itself is publicly allowed, it still requires security configurations on Bastion to protect the private infrastructure. Also, cost and maintenance (security and OS patches) associated with the Bastion itself.

Using any VPN application or service also requires maintenance and additional resource cost.

Moreover, to make the Bastion or VPN fault tolerant so that it is protected from planned or unplanned failures, it requires redundant resources that need to be provisioned, increasing the expenditure further. Operational cost increases proportionately with more security implementations for any of the above methods for accessing private resources.

A Brief Overview of Session Management with AWS SSM (Systems Manager)

The Session Manager feature of AWS SSM (Systems Manager) Managed Service allows connecting to servers and edge devices, either OnPrem machines or Virtual Machines on AWS or another cloud. It offers access to servers via GUI (Graphical User Interface) and AWS CLI (Command Line Interface). By leveraging this, users can easily connect to EC2 instances and perform all sets of operations like as SSH connections.

AWS SSM provides a secure shell and helps organizations comply with security best practices. It does not require any additional inbound ports to be open, and no public network exposure is needed for the instances. Additionally, preferences such as Idle Session Timeout, Maximum Session Duration, and Log Forwarding help to control access, and audit infra more accurately.

Advantages of Session Manager for Large Enterprises

  • Centralized User Management with AWS IAM: Unlike SSH, we can authenticate the user from a single identity store by using IAM capabilities without creating and managing users on all servers, VMs (virtual machines) or, EC2 instances.
  • No Open Inbound Ports and SSH Keys to Manage: Session Manager does not require opening any inbound port for the connection to work. There are no SSH Keys that need to be managed, simplifying user management and improving the infrastructure’s security.
  • Ease of access by Console or AWS CLI: Session Manager offers the capability to access managed instances either by AWS GUI or CLI. Both are friendly in terms of use, and the connection time is reduced.
  • Multi-Cloud/On-Premises Access: It allows us to configure AWS EC2 instances, other cloud virtual machines and even OnPrem servers for access over SSM. This enables access to other servers by a single point of authentication using AWS IAM.
  • Multi-OS Compatibility: It supports the widely used Operating Systems – Linux, macOS for SSH connectivity, and Windows for RDP connectivity.
  • Activity Logging, Auditing, and Alert Co-relation: It helps organizations to track user activity on the server by logging their activity and forwarding it to CloudWatch or S3. These audit logs can be encrypted by using AWS KMS encryption keys. Also, we can capture API calls on the Session Manager by using AWS CloudTrail. Alert notifications based on user activity and compliance requirements can be triggered by further leveraging AWS EventBridge, and SNS (Simple Notification Service).
  • Port Forwarding: Session Manager helps to redirect the server port to the local system port by which a user can access the application running inside the server as if it is running locally. This removes the need to unnecessarily expose applications to the external world unless required unnecessarily.
  • Sudo access: It allows control of the OS user with which the command is run using the Run-as functionality. Run-as functionality can be used to provide the Sudo access to the user with root/non-root permissions for the servers. It is configured based on the User/Role Tags and the IAM policies.
  • Zero/Low Operational Cost: There is no cost associated with using Session Manager for AWS EC2 instances and up to 1000 OnPrem instances or other cloud instances per AWS Account per Region. For additional instances, switching to the Advanced tier is required, and it is charged according to the number of instances and the number of hours it is used. Since no Bastion/VPN servers need to be created or managed, the operational cost is reduced.

Setting up Session Manager

Session Manager setup is quite easy, and user can achieve this by following below steps.

  • SSM Agent Installation: By default, most of the AMIs (Amazon Machine Image) available on AWS cloud have pre-installed amazon-ssm-agent. In case the agent is not installed, it can be easily installed from package managers such as yum, snap, etc.
  • IAM Role/Policy for EC2: Users can create a custom policy or use AWS managed policy AmazonSSMManagedInstanceCore. It has all the basic required permissions to get the AWS Session Manager working. You can use this policy to attach to IAM role which further attaches to EC2 Instance as an Instance Profile.
  • Outbound Traffic Configuration: AWS SSM requires communication from the managed instance to the below endpoints for outbound traffic for port HTTPS (443). Replace region with the AWS short name of the region where you have set up your AWS Systems Manager for using Session Manager.

Outbound Endpoints for SSM
ec2messages.region.amazonaws.com
ssm.region.amazonaws.com
ssmmessages.region.amazonaws.com

  • Connect using Session Manager: Once the above setup is done, we can easily take access to servers either by AWS CLI or AWS GUI. To connect to instances by GUI, go to the EC2 console page then select instance and Clicking on Connect. Just verify if Session Manager is selected on the next page and then click on connect. You will be able to access the terminal of the server once the connection is complete.

Conclusion

Session Manager setup is quick and easy and has a lot of benefits. Even though it is not able to provide a fine-grained permission segregation and access control on the servers as compared to the traditional OS level SSH authentication mechanism, its ease of management and security makes it a perfect tool to implement for your infrastructure which is on AWS, any different cloud provider or even OnPrem.

Are you looking for an AWS Partner to help implement your infrastructure on Cloud?
Connect with Us
This website uses cookies to improve your web experience.