search

aws / aws-ec2-instance-connect-cli

This is an all-in-one client for EC2 Instance Connect that handles key brokerage and establishing connection to EC2 Instances through an interface near-identical to standard system ssh, sftp, and other utilities.
Apache License 2.0
159 stars 42 forks source link

Please support "-W" pass through to ssh to allow bastion connections #2

Open tyrken opened 5 years ago

tyrken commented 5 years ago

We use bastions to connect to underlying instances, and so the "-W" parameter to ssh to do so securely (no agent forwarding). I'm hoping this would be not difficult to add to the "supported ssh flags" to let through.

tyrken commented 5 years ago

Hmm - not sure how useful bastions will be at scale if two people try to use ec2-connect via the same bastion at the same time with same "ec2-user" user. Will both keys be published & accepted as with multiple keys in an "authorized_keys" file, or can only one be published at one time?

gregmoy commented 5 years ago

EC2 Instance Connect does not use the authorized_keys file.

LordAlfredo commented 5 years ago

Thank you for the feedback. Bastioning is tricky since theyr'e multiple hosts involved and there's the question of whether or not it's an EC2 instance. Can we get some more detail on what you're looking for bastion-wise? Are your bastions EC2 instances themselves (eg, for connecting to a private subnet)?

gregmoy is correct - EC2 Instance Connect is based on keys published through the EIC service and read through EC2's instance metadata service (see our reference implementation). The authorized_keys file is not used.

tdmalone commented 5 years ago

Will both keys be published & accepted as with multiple keys in an "authorized_keys" file, or can only one be published at one time?

@tyrken I tested this - both keys are published and accepted, the metadata service simply lists them both on separate lines just like the authorized_keys file would. I didn't do enough testing to determine how this interacts with the 60 second timeout though - I recall that adding the second key seemed to extend the timeout of the first but I didn't completely test this behaviour.

tyrken commented 5 years ago

Thanks @tdmalone - that's one worry gone.

@LordAlfredo - on the last three companies I've been in the bastions have all been EC2 instances, accessible via being in Public subnets or via Direct Connect. Then via the fix for issue #3 we could use the same keypair for both servers, maybe?

LordAlfredo commented 5 years ago

Expanding on @tdmalone : each key's timeout is tracked independently. Pushing a second key will not extend the first's lifespan.

As far as the original request goes, yes, pushing the same key (selected either via -i or inferred when -W uses a bastion instance) seems like the logical solution.

I've logged this as a feature request internally for consideration.

Hallian commented 4 years ago

My client also uses bastion/jumphosts to connect to instances in the private network. I've implemented support for bastion hosts via -J flag in pull request #11.