4 ms·

This seems like the perfect complement to replace the SSM Agent / bastion instance currently used to access AWS VPC (it is super clunky to use). This should all

by Sytten 4y ago

This seems like the perfect complement to replace the SSM Agent / bastion instance currently used to access AWS VPC (it is super clunky to use). This should allow an easier time to do reverse tunnelling to databases without having to manage SSH keys.

ryanisnan 4y ago
I'm curious, what's really clunky about SSM? Other than ensuring the pre-requisites are met, and knowing the instance-id, SSM works pretty flawlessly. You can easily write a wrapper that looks up the instance-id from the hostname, if you prefer to use it that way.
- fladrif 4y ago
  Haha I'm not sure if you were being serious, but the workflow you just outlined is the clunky part of SSM. The pre-requisites are getting all the IAM roles and permissions setup (no mean feat), installing the agent, configuring it with keys generated by another user, and getting the connection information back from the aws console. This promises to be a lot easier to setup and authenticate, install tailscale, login.
  - LilBytes 4y ago
    Installing the agent client side is no more or less tedious than installing the Tailscale client, IMO anyway. I made two scripts, one in .Net with a GUI for non-devs to grep a server hostname or tag:name in AWS that resolves to an instance ID for SSH or RDP. And another python script doing the same but without the GUI for the dev team. Works a treat. But you've already explained why it's a little tedious and now I've documented and understood why. Tailscale MagicDNS does all this nonsense for you. Yeah ok thanks for rubber ducking me I see your point now. :)
  - viraptor 4y ago
    It really seems to depend on the point of view. If you're already using AWS seriously, your hosts will have the default agent anyway, IAM is already managed in a reasonable way (iamy, tf or similar), etc. so the setup is not that hard. I'm not sure what you mean by information from the AWS console - it's usable in the terminal.
  - ryanisnan 4y ago
    I think I see what you're saying. Usually though, a lot of that stuff is single-setup. E.g., all OS's that we have deployed have the agent installed and running by default. Additionally, the instance roles are already pre-configured. There's almost zero overhead in ensuring SSM gets installed on new instances. One small benefit over TailScale here, I would think, is that I don't have to rely on another tool to gain shell access. Probably a minor win, if you're running a TailScale deployment. In either case, I'd probably want to go with a single tool just to minimize the attack surface area.
andymac4182 4y ago
That feature was recently added to SSM https://aws.amazon.com/about-aws/whats-new/2022/05/aws-systems-manager-support-port-forwarding-remote-hosts-using-session-manager/ https://aws.amazon.com/about-aws/whats-new/2022/05/aws-syste... Using something like gossm which I just put a PR in for this feature also makes this easier https://github.com/gjbae1212/gossm/pull/54 https://github.com/gjbae1212/gossm/pull/54
- LilBytes 4y ago
  Oh this is awesome, I didn't see this announced. Thanks!
dimitar 4y ago
Hmm AFAIK you don't need a bastion to use SSM agent - it even allows you access through the browser. I think you meant EC2 Instance Connect which manages temporary SSH keys.
- LilBytes 4y ago
  You need a bastion for certain infrastructure types like AWS RDS' regardless of type (SQL Server, MYSQL) as an example. You can go direct to any EC2 hosted instance but it can get a little tedious on containers in Fargate or EC2 backed. The userspace that the Daemon runs on needs SOCKS magic to get working. Which eventually works but it's a PITA to get there and maintain. So for our RDS instances and containers in ECR we use a bastion which IMO is a lot easier to manage.

by Sytten 4y ago

ryanisnan 4y ago

I'm curious, what's really clunky about SSM? Other than ensuring the pre-requisites are met, and knowing the instance-id, SSM works pretty flawlessly. You can easily write a wrapper that looks up the instance-id from the hostname, if you prefer to use it that way.

fladrif 4y ago
Haha I'm not sure if you were being serious, but the workflow you just outlined is the clunky part of SSM. The pre-requisites are getting all the IAM roles and permissions setup (no mean feat), installing the agent, configuring it with keys generated by another user, and getting the connection information back from the aws console. This promises to be a lot easier to setup and authenticate, install tailscale, login.
- LilBytes 4y ago
  Installing the agent client side is no more or less tedious than installing the Tailscale client, IMO anyway. I made two scripts, one in .Net with a GUI for non-devs to grep a server hostname or tag:name in AWS that resolves to an instance ID for SSH or RDP. And another python script doing the same but without the GUI for the dev team. Works a treat. But you've already explained why it's a little tedious and now I've documented and understood why. Tailscale MagicDNS does all this nonsense for you. Yeah ok thanks for rubber ducking me I see your point now. :)
- viraptor 4y ago
  It really seems to depend on the point of view. If you're already using AWS seriously, your hosts will have the default agent anyway, IAM is already managed in a reasonable way (iamy, tf or similar), etc. so the setup is not that hard. I'm not sure what you mean by information from the AWS console - it's usable in the terminal.
- ryanisnan 4y ago
  I think I see what you're saying. Usually though, a lot of that stuff is single-setup. E.g., all OS's that we have deployed have the agent installed and running by default. Additionally, the instance roles are already pre-configured. There's almost zero overhead in ensuring SSM gets installed on new instances. One small benefit over TailScale here, I would think, is that I don't have to rely on another tool to gain shell access. Probably a minor win, if you're running a TailScale deployment. In either case, I'd probably want to go with a single tool just to minimize the attack surface area.

andymac4182 4y ago

That feature was recently added to SSM https://aws.amazon.com/about-aws/whats-new/2022/05/aws-systems-manager-support-port-forwarding-remote-hosts-using-session-manager/ https://aws.amazon.com/about-aws/whats-new/2022/05/aws-syste... Using something like gossm which I just put a PR in for this feature also makes this easier https://github.com/gjbae1212/gossm/pull/54 https://github.com/gjbae1212/gossm/pull/54

LilBytes 4y ago
Oh this is awesome, I didn't see this announced. Thanks!

dimitar 4y ago

Hmm AFAIK you don't need a bastion to use SSM agent - it even allows you access through the browser. I think you meant EC2 Instance Connect which manages temporary SSH keys.

LilBytes 4y ago
You need a bastion for certain infrastructure types like AWS RDS' regardless of type (SQL Server, MYSQL) as an example. You can go direct to any EC2 hosted instance but it can get a little tedious on containers in Fargate or EC2 backed. The userspace that the Daemon runs on needs SOCKS magic to get working. Which eventually works but it's a PITA to get there and maintain. So for our RDS instances and containers in ECR we use a bastion which IMO is a lot easier to manage.