Be Less Vulnerable: Migrating from SSH to SSM

AWS Systems Manager offers a powerful new alternative to 30-year-old SSH

In the early days of the internet, people connected to servers using protocols like telnet, which sent unencrypted text across the network. These protocols were easy to implement, but also easy to hack: any data sent in plain text could be easily sniffed out and stolen, including usernames and passwords. Then, in 1995, Tatu Ylönen released SSH, the Secure Shell protocol, as a way to transmit encrypted data over an unsecured network — and we all lived happily ever after. Right?

Wrong. SSH is a powerful tool that paved the way for e-commerce and the internet as we know it, but it's not without vulnerabilities — most of which have to do with the administration of its servers and their public and private keys:

Keys are often reused and shared among too many computers.

Keys are often left unchanged for years, because changing them risks breaking apps and is considered too much trouble.

Keys often give root access, not because it's necessary but because it's easier for administrators.

Keys can't be managed in a central place, and instead must be changed server by server.

SSH requires port 22 to be open in order to connect, which can compromise security.

System administrators have accepted these vulnerabilities because there haven't been viable alternatives to SSH — until now.

Amazon's Systems Manager Agent (SSM) is a service for managing your cloud and on-premise security. It is an entirely new architecture for secure networking that relies on users, roles, and policies to control who gets access to which resources. It also allows permissions to be administered from one centralized location. SSM runs on Amazon Elastic Compute Cloud instances, edge devices, on-premise servers, and virtual machines, and is managed via AWS IAM (Identity and Access Management).

SSM may seem challenging... but at Maark, we've seen the benefits more than justify the learning curve.

It is powerful, feature rich, secure, and easy to manage.

SSM does require an opensource agent on each machine for the connection to be established. With the help of this agent, SSM enables many other capabilities, beyond just an interactive shell: users can run remote commands and have scheduled maintenance windows to apply patches. SSM can also be used to target specific machines or sets of machines, to, say, apply a patch to a group of development servers. The SSM agent can be installed on any supported machine, allowing an organization to take advantage of its benefits while also ensuring all connections are managed in one centralized place.

Organizations may be reluctant to replace their SSH architecture with a new one, even if SSM is easier to manage and more secure — and this is why SSM can be configured to allow SSH connections, so users and apps can connect just like they did before. (This does, of course, require SSH keys to be used and maintained.)

Implementing SSM may seem challenging at first, especially to a team with a lot of SSH experience, but at Maark, we've seen the benefits more than justify the learning curve. If you already use AWS architecture, SSM is more secure and is a better way to manage your resources, and it is certainly worth investigating.

For a full list of the SSM's features and its latest documentation, visit  https://docs.aws.amazon.com/systems-manager/latest/userguide/