You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Security improvement, this would let us close port 22 on the ec2 instance. Also since users have to create ~/.aws/credential's to deploy already, this should let them ssh out of the box, without having to grab the ssh key from the console.
Describe the solution you'd like
Get the docs here to work.
Describe alternatives you've considered
SSH directly is the main alternative. There's no fail2ban, but there is faillock to help stop attacks. SSM is ideal, but this isn't an "awful" alternative.
Additional context
The main part I'm stuck on is the ssm command itself requires you to set --target=<InstanceId>. We don't know what it is (and it changes every startup), so I'd need a bash or python script to use route53 to figure out the instance IP, then use a aws ec2 describe-instances to get the instance details based on said IP, then pass that to ssm. That's too much to put in a ssh config (without being unreadable), so we'd have to have a script in the root of this project, and maybe have them create a softlink from ~/.ssh/... to said script. (That way users get updates/bug fixes if we have to edit the script later).
If we can get this working, it'd let us block 22 on the security group completely! We just want to make sure SFTP with FileZilla (or something) works first.
If this isn't possible and we need to keep SSH, then do some work to support it more:
Add option in config to lock ssh access to specific IP or Range.
Add option to change port away from the default port
Maybe expand to each stack optionally having a unique one, in case admin want to give access to a specific user for a single stack? Maybe only if previous bullet is possible...
I'll open a new issue if it's not, just keeping the bullets here to not forget anything. I won't want to improve ssh support, only to delete it if this issue is possible, so this issue is technically a blocker in a way.
The text was updated successfully, but these errors were encountered:
Cameronsplaze
changed the title
[Feature] Use SSM Session manager instead of SSH directly
[Feature] Use SSM Session Manager instead of SSH directly
Aug 2, 2024
Cameronsplaze
changed the title
[Feature] Use SSM Session Manager instead of SSH directly
[Optimization] Use SSM Session Manager instead of SSH directly
Aug 9, 2024
Is your feature request related to a problem? Please describe.
Security improvement, this would let us close port 22 on the ec2 instance. Also since users have to create
~/.aws/credential
's to deploy already, this should let them ssh out of the box, without having to grab the ssh key from the console.Describe the solution you'd like
Get the docs here to work.
Describe alternatives you've considered
SSH directly is the main alternative. There's no
fail2ban
, but there isfaillock
to help stop attacks. SSM is ideal, but this isn't an "awful" alternative.Additional context
The main part I'm stuck on is the
ssm
command itself requires you to set--target=<InstanceId>
. We don't know what it is (and it changes every startup), so I'd need a bash or python script to use route53 to figure out the instance IP, then use aaws ec2 describe-instances
to get the instance details based on said IP, then pass that to ssm. That's too much to put in a ssh config (without being unreadable), so we'd have to have a script in the root of this project, and maybe have them create a softlink from~/.ssh/...
to said script. (That way users get updates/bug fixes if we have to edit the script later).If we can get this working, it'd let us block 22 on the security group completely! We just want to make sure SFTP with FileZilla (or something) works first.
If this isn't possible and we need to keep SSH, then do some work to support it more:
I'll open a new issue if it's not, just keeping the bullets here to not forget anything. I won't want to improve ssh support, only to delete it if this issue is possible, so this issue is technically a blocker in a way.
The text was updated successfully, but these errors were encountered: