On Thu, Feb 13, 2020 at 6:20 AM Balint Reczey <balint.rec...@canonical.com> wrote:
> @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 implementation is to modify the arguments passed to sshd instead of making changes to sshd config. 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 the 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 familiar 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 support 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 around overhead of the "security" feature. This reinforces the need to benchmark the actual overhead per connection with synthetic and actual workloakds (I suspect something like a juju deployment to Ec2 of something like k8s or the like mode with lots of instances would be a reasonable workload to compare with and without the instance connect enabled. Ryan -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1835114 Title: [MIR] ec2-instance-connect To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ec2-instance-connect/+bug/1835114/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
