Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vagrant documentation about the default insecure key, is still not updated #8058

Closed
martinandersson opened this issue Nov 30, 2016 · 4 comments
Assignees
Milestone

Comments

@martinandersson
Copy link

On December 24th, 2014, user @gou1 made a comment on #5059 that the documentation for config.ssh is misleading. This caused @gildegoma to toggle some tags and rename the issue to Vagrant documentation about default insecure key should be updated.

On July 7th, 2015, the issue was closed and subsequently locked.

But, the documentation was never updated. It is still misleading.

config.ssh.insert_key docs say that this option is true/enabled, by default.

But..

This only has an effect if you do not already use private keys for authentication or if you are relying on the default insecure key.

This sentence is kind of troublesome and my biological parser is either buggy or the exception is legit. Compare these different flavors of this sentence:

true if you do (not a) or b

true if you do not (a or b)

I vote for the latter: config.ssh.insert_key "has no effect" if the Vagrant user is "relying on the default insecure key".

Scroll up a little bit up on the page. This is what config.ssh.private_key_path has to say:

By default this is the insecure private key that ships with Vagrant, since that is what public boxes use.

So by default, Vagrant use an "insecure private key", which the first section we looked claim will render his default "true" value useless. Which option overrides the other - so to speak? Either Vagrant will use the insecure private key, or he will insert a newly generated key. Both can not be true.

Also note that the config.ssh.insert_key section say that Vagrant use two keys (a "keypair") to replace just 1.

I think that these sections need to be reworked. I also think that the community will benefit if Vagrant addressed SSH and SSH security in more detail. Currently, we have basically only 1 page that target each and every setting in config.ssh one after another in a list-like fashion without providing the user with an introduction/overview.

@hedgehog
Copy link
Contributor

hedgehog commented Dec 10, 2016

@chrisroberts and @mitchellh Apologies if this appears obtuse.

I'm on Vagrant 1.8.6

The related issues list below indicates that Vagrant private key handling is causing grief - and these issues only represent people who hang in enough to log an issue.

I think the difficulty is more than with the documentation. I note that #5005 was tagged as an enhancement... should it have been closed? I think the enhancement is still required.

Scenario

You want Vagrant to insert the public keys that correspond to a list of private keys you provide.

Current behaviour

Current behaviour can be represented as this default configuration (but I don't think it is implemented like this):

Vagrant.configure("2") do |config|
  config.ssh.insert_key = true
  ...
end

and this behaviour:

  1. Insert insecure_private_key file name in private_key_path then insert its public key in the VM's ~/.ssh/authorized_keys
  2. If no other private key exists in private_key_path, generate one and add it to the array
  3. Insert the just created key's public key in the VM's ~/.ssh/authorized_keys
  4. If 3. succeeds then remove the insecure public key from the VM's ~/.ssh/authorized_keys

Desired behaviour

Vagrant.configure("2") do |config|
  config.ssh.private_key_path = ['~/.vagrant.d/insecure_private_key',
                                 '~/.aws/private_key']
  config.ssh.insert_key = true
end

and this behaviour:

  1. For each private key in private_key_path if insert_key = true then generate its public key (ssh-keygen -y -e -f "$PRIVKEY") and insert its public key in the VM's ~/.ssh/authorized_keys
  2. If 1. succeeds and insecure_private_key is the name of any file private_key_path then remove the insecure public key from the VM's ~/.ssh/authorized_keys

Current workaround

Vagrant.configure("2") do |config|

  config.vm.define "ami", primary: true do |ami|
      override.ssh.insert_key = false
      override.ssh.username = 'vagrant'
      override.ssh.private_key_path = [ '~/.vagrant.d/insecure_private_key',
                                        '~/.aws/private_key.pem' ] 

  end
  pub_key = `ssh-keygen -y -e -f '~/.aws/private_key.pem'`
  config.ssh.insert_key = false
  config.vm.provision "shell", inline: <<-EOC
    echo '#{pub_key}' >> /home/vagrant/.ssh/authorized_keys
    sed --in-place=.bak -r 's/^#?(PermitRootLogin|PermitEmptyPasswords|PasswordAuthentication|X11Forwarding) yes/\1 no/' /etc/ssh/sshd_config
    sed --in-place=.bak '/== vagrant insecure public key$/d' /home/vagrant/.ssh/authorized_keys
    sed --in-place=.bak '$!N; /^\(.*\)\n\1$/!P; D' /home/vagrant/.ssh/authorized_keys
    sudo service ssh restart
  EOC
  end
  config.vm.provision 'chef_zero' do |chef|
  ...
  end

Related:

#4707
#4967
#5005
#5090
#8102
#5186
#5780
#6406
#7610
#8037
http://ermaker.github.io/blog/2015/11/18/change-insecure-key-to-my-own-key-on-vagrant.html

@kikitux
Copy link
Contributor

kikitux commented Dec 10, 2016

@MartinanderssonDotcom

Is all about the workflow.

If you creare your own VM or AMI using your own pair of keys you should use:

config.ssh.private_key_path
config.ssh.insert_key=false

To create custom boxes or customize AMI we have the tool packer.

The 2 options private_key_path is only to be used to tell vagrant with private key to use to login to the box.

The insert_key is to make the publics VM a bit more secure.

@avoidik
Copy link

avoidik commented Jan 17, 2018

@hedgehog Vagrant gets crazy with your workaround, I guess it's related to first sed command

@ghost
Copy link

ghost commented Jan 28, 2020

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@ghost ghost locked and limited conversation to collaborators Jan 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants