[CentOS-devel] Feedback needed: ideas for the Vagrant images

[Nico Kadel-Garcia]

On Thu, Jul 7, 2016 at 8:53 AM, Laurentiu Pancescu <lpancescu at 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.