Please don't merge this. We're using this feature for testing (tmt) on various boxes. All of boxes we use do have this key as well. We'd have to workaround it, which would cause the spin-up process to take even longer...

Is having an insecure key on some testing network (or just your laptop) really an issue? Or do people use Vagrant for production instances? (Why?!)

so tmt requires the vagrant insecure key to be used to ssh into the vagrant box as the root user? could it use the vagrant user?

@pvalena can you answer @dustymabe 's questions? Should we discuss this somewhere else?

@dustymabe hello, was a bit overwhelmed by work, sorry for taking so long.

Yes root is the expected user to run the tests. We'd need to workaround that for fedora boxes.

To elaborate more: for TMT, we'd need to do additional step to gain 'root' for every command, so most probably we'd inject the VM with the said key manually (which is unpreffered, because that would be additional manipulation with a VM, which is considered pre-prepared env and this would diverge for that).

You can reach me on IRC, if you need, but I'll respond (promptly) here as well.

It seems like this should be easy to automate a solution to without leaving one account open to a key that is known around the world. With ansible there is become to activate privileged escalation.

https://docs.ansible.com/ansible/latest/user_guide/become.html#become-directives

Can we just enhance TMT to assume the vagrant user and login and copy the dynamically generated key over using sudo cp /home/vagrant/.ssh/authorized_keys /root/.ssh/authorized_keys ?

It seems like this should be easy to automate a solution to without leaving one account open to a key that is known around the world. With ansible there is become to activate privileged escalation.
https://docs.ansible.com/ansible/latest/user_guide/become.html#become-directives
Can we just enhance TMT to assume the vagrant user and login and copy the dynamically generated key over using sudo cp /home/vagrant/.ssh/authorized_keys /root/.ssh/authorized_keys ?

Well, yes and no. Automate: yes, basically, but we'd need to add additional steps and logic which slows down and complicates the provisioning. But no, we cannot even assume we have vagrant user. Some of the boxes we use have "only" the root user (and there's no intention/reason to add "vagrant" one). So while it seems simple when we only work with Fedora boxes, it gets complicated when we have more of them. We'd need to detect the Fedora ones, and push the root key.

BTW. does privilleged: true for provisioning work, when there's no root key? If not, that may break several Vagranfiles/workflows/projects that I know of.

Anyway, I still cannot see your point "leaving one account open".. you mean that with first connection, the insecure key is changed, right? That may be an issue, if you expose the SSH outside of the network vagrant uses. But at that point, we still keep user "vagrant", so basically it's still accessible with default pasword "vagrant", or am I mistaken?

Anyway, I still cannot see your point "leaving one account open".. you mean that with first connection, the insecure key is changed, right?

On the first connection the insecure key for the vagrant user is changed, but the insecure key is left in place for the root user.

That may be an issue, if you expose the SSH outside of the network vagrant uses. But at that point, we still keep user "vagrant", so basically it's still accessible with default pasword "vagrant", or am I mistaken?

Right, it's still pretty insecure, I was just trying to improve things slightly :smile:

Anyway, I still cannot see your point "leaving one account open".. you mean that with first connection, the insecure key is changed, right?

On the first connection the insecure key for the vagrant user is changed, but the insecure key is left in place for the root user.

Yes, you're right. Maybe vagrant could replace root keys as well (optionaly)? I agree that having secure boxes by default should be preferred way, until Vagrant does this by default.

That may be an issue, if you expose the SSH outside of the network vagrant uses. But at that point, we still keep user "vagrant", so basically it's still accessible with default pasword "vagrant", or am I mistaken?

Right, it's still pretty insecure, I was just trying to improve things slightly :smile:

That looks like an RFE for Vagrant as well (scramble password).
Well, in case this is accepted, I've implemented root ssh keys replacement in one project. It works reliably, across all boxes:

  config.vm.provision "shell", privileged: true, run: "once", inline: <<-EOS
    set -xe
    cp -rf /home/vagrant/.ssh/ /root/
    sed -i "s/^[\#\s]*PermitRootLogin.*$/PermitRootLogin yes/" /etc/ssh/sshd_config
    service sshd restart
    restorecon -R -v /root/.ssh
  EOS

  # If running `vagrant ssh` command, use 'root' user
  if ARGV.first == "ssh"
    puts "Logging in as root."
    config.ssh.username = "root"
  end

Which could be also supported on Vagrant-side.
Note: I use Vagrant & some-Vagrant-plugin interchangably. As having a plugin is sufficient for all optional use-cases, so there's no need to propose the changes in main repo.

Yeah I'll close this for now. Thanks for the discussion @pvalena

Yeah I'll close this for now. Thanks for the discussion @pvalena

Sorry, maybe I was being too cryptic- to make it more clear:

I agree with removing the root key (this PR) and thus making it more secure, because there are other ways to make it work.