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

[tyrken]

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]

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]

EC2 Instance Connect does not use the authorized_keys file.

[LordAlfredo]

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]

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]

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]

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]

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.