On Thu, Jul 7, 2016 at 6:53 AM, Laurentiu Pancescu lpancescu@gmail.com wrote:

IV. disable requiretty in /etc/sudoers: this allows users to enable the pipelining feature of the Ansible provisioner, which significantly increases its speed (it's about 2 times faster in my tests). [3]

I think that this requirement is going away in the latest versions of Ansible? See https://github.com/ansible/ansible/pull/13200

- Ken

On 07/07/2016 06:23 PM, Laurentiu Pancescu wrote:

Hi there,

I would appreciate some feedback on a few ideas for our Vagrant images.

Our CentOS images for Vagrant are currently not setup according to the upstream recommendations for base boxes, and I'd like to change that. [1] Here's the list of necessary modifications:

I. root password should be 'vagrant': already filed by Lalatendu Mohanty as issue #30 on GitHub [2]. I should mention that Karanbir Singh has some reservations related to security. However, the box already has passwordless sudo, and changing the root password is just a "sudo passwd" away (I tried, it warns about a bad password, but it accepts it). Although public key auth is enabled, password-based authentication isn't disabled, and sshd will happily let anyone log in to any public box as vagrant:vagrant. We should probably only allow local password logins (on the console), for both root and vagrant; not sure if the best way to enforce this is sshd_config or PAM.

+1. I think we should keep the behavior as per upstream Vagrant documentation.

II. use /vagrant as the sync directory: we currently use /home/vagrant/sync, this change is already planned for the release following 1606

III. "UseDNS no" in sshd_config: this would make connections via ssh faster

Additional ideas for optimization:

IV. disable requiretty in /etc/sudoers: this allows users to enable the pipelining feature of the Ansible provisioner, which significantly increases its speed (it's about 2 times faster in my tests). [3]

V. set GRUB_TIMEOUT to 1 or 0: this reduces or eliminates the waiting time before the default kernel is booted (the VM runs generally without a display, so it makes no sense to wait there)

Best regards, Laurențiu

[1] https://www.vagrantup.com/docs/boxes/base.html [2] https://github.com/CentOS/sig-cloud-instance-build/issues/30 [3] https://docs.ansible.com/ansible/intro_configuration.html#pipelining _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel

On Thu, Jul 7, 2016 at 8:53 AM, Laurentiu Pancescu lpancescu@gmail.com wrote:

III. "UseDNS no" in sshd_config: this would make connections via ssh faster

this is an old feature, and the "fix" is incomplete. What you really want is "-u0" for sshd set in /etc/sysconfig/sshd. Why? Because according to the man page:

UseDNS Specifies whether sshd(8) should look up the remote host name, and to check that the resolved host name for the remote IP address maps back to the very same IP address.

If this option is set to “no” (the default) then only addresses and not host names may be used in ~/.ssh/known_hosts from and sshd_config Match Host directives.

Unfortunately, it still does the reverse DNS lookup even with UseDNS=no. And it's the lengthy discovery that an incoming IP address has no valid reverse DNS that often makes initial SSH connections take so long. There is *no* option for sshd_config that turns off the reverse DNS lookups. This is a very old problem, best resolved by using the less popular "sshd -u0" pitions from /etc/sysocnfig/sshd.

Been there, done that, solved a lot of cross-communications problems for a network of more than 10,000 distributed hosts when I set that option by default about 15 years ago.

There is a trade-off: you forego the DNS lookups on logged connections, and with a dynamic DNS environment this can reflect the valid hostname of the connecting host. But the tradeoff in performance for large environments trying to run SSH scans against dozens or hundreds of machines, and with poor reverse DNS setups, can be a real problem.

Additional ideas for optimization:

IV. disable requiretty in /etc/sudoers: this allows users to enable the pipelining feature of the Ansible provisioner, which significantly increases its speed (it's about 2 times faster in my tests). [3]

That's a noticeable security tradeoff. Denying sudo to cron jobs, or "at" jobs, and enforcing the presence of a tty can help restrict abusive tasks left behind by users. It can also help prevent the use of sudo by unattended daemons: I've seen users, like the "mysql" user, given various passphrase free sudo access for weird development situations. I'd prefer for safety that those not be enabled for unattended sudo access by default.

That makes it worth thinking about before changing. I'm not morally opposed to it, but it's worth more than a few moments of thought.

V. set GRUB_TIMEOUT to 1 or 0: this reduces or eliminates the waiting time before the default kernel is booted (the VM runs generally without a display, so it makes no sense to wait there)

For vagrant images, I can see this. For any system where a developer might need to control grub and select a kernel to roll back to, or switch to single user mode, I'd see it as making the grub selections unavailable. For those systems, it's worsened by lengthy BIOS times, the time burned changing screen resolution from one display mode to another, the difficulty of hitting the 5 second window after 5 minutes of staring at useless hardware boot screens.

But for Vagrant images? Yeah, makes sense.