>I also wouldn't call this a loophole, you have to explicitly have permissions to use SSM.
Perhaps not the best wording on my part. I was aware of SSM, but not aware of the SSH tunneling features. I'm wondering if that's common. Is the SSH tunneling controlled separately, or on by default if SSM is on?
Re:Emacs Tramp over AWS SSM APIs
by awsthro00945 on Tuesday July 13, 2021 @03:00PM
(#27824816)
It is "on" by default, but the user still has to have the 'ssm:StartSession' permission (and probably others) to open the SSM session, and for some(?) operations you also still need to have the appropriate credentials (ssh keypair or a password) to login via SSH.
SSM Session Manager is one of the (if not the) preferred way to manage SSH access to instances in AWS. It's kinda hairy to set up, but it removes the need for bastion hosts/jump boxes for most use cases. From my experience I would say it is quite common.
Installing Yet Another Agent on your cluster/VMS and ensuring they are updated while the SSM agent got an upgrade I believe from python to go it still does a lot more than just provide ssh sessions correct?
Re:Emacs Tramp over AWS SSM APIs
by staticassertion on Tuesday July 13, 2021 @03:30PM
(#27825191)
I don't really know much about the agent. I'm not super concerned with keeping it updated though.
1. You don't have to expose a jump host at all, which is one less exposed asset to manage and worry about.
2. Your security team should already be collecting Cloudtrail logs, so they get auditing of SSM/SSH "for free".
3. You can control SSM access via your SSO provider, which means you can trivially enforce a bunch of policies all in one place vs having to configure SSHD.
4. You can control SSM access via IAM.
5. You can limit session duration easily.
6. No more SSH agent hijacking, at least I don't think.
I also wouldn't call this a loophole, you have to explicitly have permissions to use SSM.