Vagrant insécurité par défaut?

Question

Par suite de la mise en route des instructions sur la vagrantup.com, j'ai l'impression de se retrouver avec une machine virtuelle qui accepte les connexions SSH sur le port 2222, de sorte que n'importe qui peut obtenir l'accès root de ma VM et de lire mon hôte répertoire de travail en utilisant les informations d'identification par défaut (nom d'utilisateur=mot de passe=vagabond ou vagrant_insecure_private_key).

Est-ce vrai? Si oui, pourquoi n'est-il pas considéré comme une faille de sécurité béante? Que faire si j'avais copié les données sensibles à la VM?

EDIT: et pour ceux qui pense que n'importe qui sur internet, être capable de lire vos sources et l'exécution de code arbitraire sur votre machine virtuelle n'est pas mauvais en soit, je recommande la lecture de la "Rupture" à l'article dans ce blog http://finite.state.io/blog/2012/10/30/breaking-in-and-out-of-vagrant/

En un mot: la course Erratique "comme prévu" peut également permettre à quiconque de pénétrer dans votre hôte/machine de développement (p. ex., à l'aide d'un malveillant git post-commit hook).

Answer 1

La réponse courte est OUI.

Pourquoi?

Lors de la construction de l'Errance de la base de boîtes (manuellement ou à l'aide d'outils comme Veewee à automatiser), les constructeurs de suivre le vagabond de la base de boîtes de spécifications qui définit les éléments suivants:

1. L'utilisateur root et vagrant utiliser vagrant comme mot de passe
2. La clé publique d'authentification (mot de passe) pour l'utilisateur vagrant.

Vagrant projet fournit une insécurité paire de clés SSH Authentification par Clé Publique de sorte qu' vagrant ssh travaux.

Parce que tout le monde a accès à la clé privée, n'importe qui peut utiliser la clé privée pour vous connecter à votre VMs (supposons qu'ils connaissent votre adresse IP de la machine hôte, le port par défaut 2222 que les règles de transfert en place.)

Il n'est PAS sûr OOTB. Toutefois, vous pouvez supprimer la clé de confiance à partir d' ~vagrant/.ssh/authorized_keys et ajouter votre propre, changer de mot de passe pour vagrant et root, alors qu'il est considéré comme relativement sûr.

Mise à jour

Depuis Vagrant 1.2.3, par défaut de SSH port transféré lie à l'adresse 127.0.0.1, de sorte que les connexions locales sont autorisées [GH-1785].

Answer 2

J'ai soulevé cette question sur le dépôt github pour vagrant. Le développeur a dit qu'ils vont résoudre le problème avec l'transmis ports externes disponibles. Le développeur accepte cependant pas la question concernant la compromission de l'environnement hôte de la machine virtuelle. Je pense qu'ils sont dangereusement erronée.

https://github.com/mitchellh/vagrant/issues/1785

Sortir de la vm est plus facile que la lié billet de blog suggère. Vous n'avez pas à dépendre de git crochets de compromettre l'hôte, il vous suffit de mettre arbitraire de code ruby dans l'Errance de fichier.

J'ai couru le vagabond dans une VM sandbox si je le pouvais. Puisque je ne peux pas, j'ai du faire avec un pare-feu.

C'est une bonne idée d'avoir des règles de dimensionnement pour ajouter une sécurité de clé ssh, et à la suppression de la précarité de la clé et le mot de passe par défaut.

Answer 3

J'ai écrit cette simple inline coque provisioner de swap sur les authorized_keys avec mon id_rsa.pub. Une fois configuré le insecure_private_key ne peut pas être utilisé pour s'authentifier.

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

# ...

  config.ssh.shell = "bash -c 'BASH_ENV=/etc/profile exec bash'" # avoids 'stdin: is not a tty' error.

  config.ssh.private_key_path = ["#{ENV['HOME']}/.ssh/id_rsa","#{ENV['HOME']}/.vagrant.d/insecure_private_key"]

  config.vm.provision "shell", inline: <<-SCRIPT
    printf "%s\n" "#{File.read("#{ENV['HOME']}/.ssh/id_rsa.pub")}" > /home/vagrant/.ssh/authorized_keys
    chown -R vagrant:vagrant /home/vagrant/.ssh
  SCRIPT

end

Answer 4

En tant que Vagabond 1.2.3 la valeur par défaut est de se lier à localhost au lieu de l'interface publique, en évitant le problème de connexion externe.