Linux without SSH? It's possible with Amazon SSM

In a computer park with linux machines, SSH is something classic. Very often scanned, regularly badly secured, it is also a possible entry point for attacks. Moreover, the problem of SSH traceability often pushes companies to set up specific processes.

On Amazon, it has been possible since last year to log in using SSH without the need for a key, login or password... and without SSH.

SSM - Systems Manager Agent: Amazon-style configuration manager

Amazon makes it easy to deploy server fleets, however, deploying a server is easy, maintaining it is not necessarily. Many companies will probably choose to use Ansible, Puppet, Chef or another manager configuration.

However, Amazon also provides the SSM service which allows among others :

• To update applications remotely according to specified criteria (tags for example).
• Audit of the binaries installed on the machines (installed packages, version etc...)
• Report generation following these audits
• Remote connection to machines

It is this last feature that interests us in this article.

SSM - Secure and traceable connection to a Linux instance

On AWS, by default, the connection is made using public keys deployed on the server. This raises the question of the rotation of these keys, their storage location, who owns the key, the fact that it can be shared beyond the scope initially planned etc...

Solutions exist to manage keys in other ways, I think in particular of Netflix's BLESS (Bastion's Lambda Ephemeral SSH Service - GitHub). However, these solutions require complexity both on its implementation and on its MCO. Indeed, the installed brick becomes directly critical, being necessary for the slightest connection on a machine.

An alternative in service mode is possible through Amazon SSM. The advantages of this connection mode are multiple:

• Federated access through AWS IAM, a policy is required to access the machines, and this policy can be very detailed.
• Recording of all actions on a log file available on S3, and easily secured or centralized.
• No more need to open port 22 on machines
• No configuration/installation needed if you are on a machine running an Amazon Linux image

SSH via SSM in action

For the purpose of this article, I created a machine running an Amazon Linux 2 and having the "AmazonEC2RoleforSSM" (AWS Managed Policy) policy, this policy is far too permissive to be used in a productive environment, but sufficient for this poc. This machine has no open port in inbound.

I have not deployed any SSH keys on the machine.

I have configured SSM to log all actions in an S3 bucket:

The user I'm using is also too permissive and uses the "AmazonSSMFullAccess" (AWS Managed Policy), again, in production, we will limit permissions as much as possible.

I also installed on my client PC the "session-manager-plugin" package needed to establish the connection (installation documentation available here).

Now that all these prerequisites are ready, I can connect to my machine.

Two methods are available:

Connection via a "classic" Shell

I connect from my shell, but instead of typing ssh user@ip I go through the Amazon CLI, then I do some commands for the demo, as you can see, the shell behavior is the same as in SSH, including the tab completion :

A few minutes after the connection, the associated log is available on S3

If you go to the log, you'll find:

• The commands I typed
• The returned content I've been getting

Connection through the SSM console

It is also possible to connect through the SSM console by clicking on "Start session" from the SSM home page.

I then choose my machine and click on "Start session" once again. Please note that only machines with SSM installed and the role allowing SSM to run are listed here, there may be a one to two minute latency before a machine appears.

I'm retyping the same commands as above, once again, the behavior is the same as a regular shell, and interestingly compared to many online console emulation that are slow, the latency is very good, and the usage is fluid. Once again, we can still use tab completion.

Just like before, the log is then on the s3 bucket I set up, and all the commands I entered can be found.

In conclusion

SSM provides a reliable and secure alternative to traditional SSH, centralizing access and forcing authentication to access any resource. It also allows to limit the attack vectors, since it does not require any additional port opening. It allows fine filtering, adapted to Amazon's model (for example, we can give access to machines with only certain tag combinations), while ensuring complete traceability of actions.

Finally, it eliminates the need to manage SSH keys, which implies :

• No more safes to store them
• No more rotations to set up
• No more implementation and MCO of the use of these keys