← Back to team overview

cloud-init-dev team mailing list archive

Re: [Bug 1835114] Re: [MIR] ec2-instance-connect


On Thu, Feb 13, 2020 at 6:20 AM Balint Reczey <balint.reczey@xxxxxxxxxxxxx>

> @raharper I agree with the concern regarding the manipulation of sshd
> config. To minimize the collision with cloud-init this package does not
> change /etc/ssh/sshd_config like cloud-init does, but overrides the
> configuration value with a systemd drop-in. The drop-in is placed at the

This does not avoid a collision with cloud-init.  That is, the current
is to modify the arguments passed to sshd instead of making changes to sshd
Multiple sources of configuration is still an issue.  Someone inspecting
sshd config will
not see that the AuthorizedKeyCommand is being passed via arguments,
further they
may not know where this additional override is coming from w.r.t the
systemd drop-in
config.  If a user (or program via cloud-init config) were to modify sshd
config and
set their own AuthorizedKeyCommand, this scenario will fail for them since
ec2-instance-connect drop in will always take precedence.

Shouldn't the drop-in program examine sshd config?

> Regarding the potential user confusion when the user also sets ssh keys
> using cloud-init eic_run_authorized_keys is designed to _merge_ the keys
> used by Instance Connect with the other keys in use thus the users can
> continue to use their keys deployed by cloud-init or the ones deployed
> by other means.

Could you elaborate (or point to documentation) on this merging?   I'm
with how AuthorizedKeyCommand works if it does not produce any output, sshd
will fall back to AuthorizedKey files specifiedin sshd_config; but I've not
seen any
discussion on the merging you suggest.

> I also agree that there is additional overhead for each ssh connection,
> but while testing the package I have not found that excessive. We may

Instead of vague statements, capturing actual values would be most useful.

> need further evaluation of the impact on the ssh service before adding
> the package to the AMIs by default, but I think this can be done after
> finishing the MIR process.

I generally disagree with letting something in to main that we want to
and "we can fix this after we agree to MIR".

> Upstream already answered @paelzer's caching proposal, and the package
> is installed on Amazon Linux 2 by default already, thus I believe
> upstream's attention is warranted regarding the overhead.

The response is dismissive; security and usability override any concern
overhead of the "security" feature.  This reinforces the need to benchmark
actual overhead per connection with synthetic and actual workloakds (I
something like a juju deployment to Ec2 of something like k8s or the like
with lots of instances would be a reasonable workload to compare with and
the instance connect enabled.


Follow ups