amazon-ssm-agent

Don't overlook SSM <https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/session-...> which doesn't require sshd nor public access to get onto a machine and one can opt in to a bunch of audit logging if that's your jam. They also have some "ansible-y" behavior about running playbooks against groups of instances, but I haven't had good experiences with that process in order to recommend it. It's just a small bonus that one can also hop onto an instance from the AWS Console when using SSM, since it is websocket based and not "ssh from the browser" The agent is Apache 2 if one wanted to build, enhance, or audit what it does: https://github.com/aws/amazon-ssm-agent#readme as is the local binary that awscli uses for the websocket handshaking: https://github.com/aws/session-manager-plugin#readme

Annoyingly SSM still requires managing ssh keys and users somehow, it really only takes care of the network layer. I have been thinking of combining SSM with EC2 Instance Connect to deal with that issue, but haven't gotten around to actually implement that. Also SSM has some annoying glitches like e.g. https://github.com/aws/amazon-ssm-agent/issues/274 Edit: found this blog post that shows how the two can work together https://skorfmann.com/blog/aws-ecs-instance-connect-meets-aw...

FWIW, the project is open source, so you could build a modified agent for your purposes and inject it via cloud-init or your favorite config management tool: https://github.com/aws/amazon-ssm-agent

Last I checked the "tunneling" only works to redirect traffic to a different port on the same SSM managed instance. The tunnel cannot be established with another box in the same VPC. So I don't think you can call it tunneling until they add that feature. Here's the GitHub issue where they discuss the limitation and a workaround: https://github.com/aws/amazon-ssm-agent/issues/208