We've been using SSH over SSM at work, and it's been great for tying access to IAM credentials.
Using the SSM tool as a ProxyCommand for OpenSSH is brilliant. I can SSH to an instance (turning on agent forwarding, etc.) or SCP files back and forth, all the same way that I'd do it with a regular host. But that host doesn't need to be exposed to inbound SSH traffic!
I was also able to get the ProxyCommand working in a Docker container, so I don't have to install the AWS CLI or the SSM plugin on my (Linux) host system, with an .ssh/config entry like this:
* We often use our bastions to do port forwarding, e.g. to connect to an RDS instance inside VPC. As far as I know, we can't accomplish this with just SSH over SSM, so we still keep our bastions.
* User management: SSH over SSM doesn't do any user or key management for you (which makes sense). It establishes the SSH connection and you're on your own from there. We use Keymaker [1] to dynamically create user accounts on the EC2 instances, and populate SSH keys according to the user's IAM profile. This works fine, but maybe there's room for simplification.
* Connecting based on instance ids (`ssh i-...`) can be awkward. It would be amazing if we could alias these somehow, like set up a CNAME that points to `i-...`. I wasn't able to get OpenSSH to follow a CNAME and then use the ProxyCommand. Maybe it's possible, though.
To make the ProxyCommand setup a little easier, perhaps you could use `aws ec2 describe-instances` with the appropriate filter? For example, the article I linked uses:
to grab the instance ID from the Name tag. You could set up a shell script as a ProxyCommand to do this automatically, although beware that ProxyCommand's %h will always lowercase the input...
Comments
We've been using SSH over SSM at work, and it's been great for tying access to IAM credentials.
Using the SSM tool as a ProxyCommand for OpenSSH is brilliant. I can SSH to an instance (turning on agent forwarding, etc.) or SCP files back and forth, all the same way that I'd do it with a regular host. But that host doesn't need to be exposed to inbound SSH traffic!
I was also able to get the ProxyCommand working in a Docker container, so I don't have to install the AWS CLI or the SSM plugin on my (Linux) host system, with an .ssh/config entry like this:
A few problems in practice:* We often use our bastions to do port forwarding, e.g. to connect to an RDS instance inside VPC. As far as I know, we can't accomplish this with just SSH over SSM, so we still keep our bastions.
* User management: SSH over SSM doesn't do any user or key management for you (which makes sense). It establishes the SSH connection and you're on your own from there. We use Keymaker [1] to dynamically create user accounts on the EC2 instances, and populate SSH keys according to the user's IAM profile. This works fine, but maybe there's room for simplification.
* Connecting based on instance ids (`ssh i-...`) can be awkward. It would be amazing if we could alias these somehow, like set up a CNAME that points to `i-...`. I wasn't able to get OpenSSH to follow a CNAME and then use the ProxyCommand. Maybe it's possible, though.
[1] https://github.com/kislyuk/keymaker
I haven't used it or looked into what it supports, but I did remember this announcement which may interest you: "New – Port Forwarding Using AWS System Manager Session Manager": https://aws.amazon.com/blogs/aws/new-port-forwarding-using-a...
To make the ProxyCommand setup a little easier, perhaps you could use `aws ec2 describe-instances` with the appropriate filter? For example, the article I linked uses:
to grab the instance ID from the Name tag. You could set up a shell script as a ProxyCommand to do this automatically, although beware that ProxyCommand's %h will always lowercase the input...