Nie można ssh włamać się do maszyn wirtualnych za pomocą niezabezpieczonego klucza prywatnego (vagrant 1.7.2)

Question

Mam klaster 3 maszyn wirtualnych. Oto Vagrantfile:

# -*- mode: ruby -*- 
# vi: set ft=ruby : 


hosts = { 
    "host0" => "192.168.33.10", 
    "host1" => "192.168.33.11", 
    "host2" => "192.168.33.12" 
} 

Vagrant.configure("2") do |config| 
    config.vm.box = "precise64" 
    config.vm.box_url = "http://files.vagrantup.com/precise64.box" 
    config.ssh.private_key_path = File.expand_path('~/.vagrant.d/insecure_private_key') 

    hosts.each do |name, ip| 
    config.vm.define name do |machine| 
     machine.vm.hostname = "%s.example.org" % name 
     machine.vm.network :private_network, ip: ip 
     machine.vm.provider "virtualbox" do |v| 
      v.name = name 
     # #v.customize ["modifyvm", :id, "--memory", 200] 
     end 
    end 
    end 
end 

To używane do pracy, dopóki nie zmodernizowane ostatnio:

ssh -i ~/.vagrant.d/insecure_private_key vagrant@192.168.33.10 

Zamiast włóczęga pyta o hasło.

Wygląda na to, że ostatnie wersje vagrant (w wersji 1.7.2) tworzą bezpieczny klucz prywatny dla każdej maszyny. Wykryłam to, uruchamiając

vagrant ssh-config 

Dane wyjściowe pokazują różne klucze dla każdego hosta. Weryfikowałem, że klawisze są różne, różnicując je.

Próbowałem wymusić niezabezpieczony klucz, ustawiając w Vagrantfile ścieżkę config.ssh.private_key_path, ale to nie działa.

Powodem, dla którego chcę użyć klucza niezabezpieczonego dla wszystkich maszyn, jest to, że chcę je udostępnić z zewnątrz za pomocą ansibla. Nie chcę korzystać z mechanizmu przekazywania odpowiedzi, ale traktuj maszyny wirtualne jako serwery zdalne. Tak więc Vagrantfile jest właśnie używany do określania maszyn w klastrze, a następnie udostępnianie będzie wykonywane zewnętrznie.

Dokumentacja wciąż mówi, że domyślnie maszyny będą używać niezabezpieczonego klucza prywatnego.

W jaki sposób mogę sprawić, aby moje maszyny wirtualne korzystały z niezabezpieczonego klucza prywatnego?

Answer 1

Vagrant zmienił zachowanie między wersjami 1.6 i 1.7, a teraz wstawi automatycznie wygenerowany klucz niezabezpieczony zamiast domyślnego.

Możesz anulować to zachowanie, ustawiając config.ssh.insert_key = false w swoim pliku Vagrantfile.

Vagrant nie powinny zastąpić klucz niezabezpieczone jeśli podasz private_key_path jak ty, jednak wewnętrzne kontrole logiczne jeśli private_key_path wskazuje domyślny insecure_private_key, a jeśli tak, Vagrant będzie go zastąpić.

Więcej informacji można znaleźć pod adresem here.

Answer 2

tldr;

ssh vagrant@127.0.0.1 -p2222 -i/~/www/vw/vw-environment/.vagrant/machines/default/virtualbox/private_key 

nie mogłem dostać to do pracy, więc w końcu dodaje się następujący wiersz do skryptu ssh.rb rubinowym (/opt/vagrant/embedded/gems/gems/vagrant-1.7.1//lib/vagrant/util/ssh.rb)

print(*command_options) 

tuż przed tym wierszu, który wykonuje połączenia ssh

SafeExec.exec("ssh", *command_options) 

Tak, że wypisuje wszystkie przekazane do połączenia ssh opcje polecenia, stamtąd można wypracować coś, co działa dla Ciebie w oparciu o to, co włóczęga oblicza się za prawidłowe ssh parametry.

Answer 3

Gdy Vagrant tworzy nowy klucz ssh, jest zapisywany z domyślną konfiguracją pod katalogiem Vagrantfile pod numerem .vagrant/machines/default/virtualbox/private_key.

Korzystanie z wygenerowany automatycznie klucz można zalogować się, że w tym samym katalogu co Vagrantfile jak ten:

ssh -i .vagrant/machines/default/virtualbox/private_key -p 2222 vagrant@localhost 

aby poznać wszystkie szczegóły na temat aktualnej konfiguracji ssh z Vagrant polu używania Vagrant ssh- config command.

# vagrant ssh-config 
Host default 
    HostName 127.0.0.1 
    User vagrant 
    Port 2222 
    UserKnownHostsFile /dev/null 
    StrictHostKeyChecking no 
    PasswordAuthentication no 
    IdentityFile /Users/babo/src/centos/.vagrant/machines/default/virtualbox/private_key 
    IdentitiesOnly yes 
    LogLevel FATAL 

Answer 4

Dodawanie config.ssh.insert_key = false do Vagrantfile i usuwanie nowy VM klucz prywatny .vagrant/machines/default/virtualbox/private_key włóczęga automatycznie aktualizuje vagrant ssh-config z odpowiednim kluczem prywatnym ~/.vagrant.d/insecure_private_key. Ostatnią rzeczą, którą musiałem zrobić, to ssh w vm i zaktualizować autoryzowany plik kluczy na vm. curl https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub > ~/.ssh/authorized_keys

Answer 5

Jeśli konkretnie przy użyciu ansibl (nie Provisioner Vagrant ansibl), warto rozważyć użycie Vagrant skrypt dynamiczny zapasów z repo ansibl za:

• https://github.com/ansible/ansible/blob/devel/contrib/inventory/vagrant.py

Alternatywnie, ty "może wykonać swój własny skrypt i dynamicznie zbudować plik inwentarza włóczęgi:

SYSTEMS=$(vagrant status | grep running | cut -d ' ' -f1) 

echo '[vagrant_systems]' > vagrant.ini 

for SYSTEM in ${SYSTEMS}; do 
    SSHCONFIG=$(vagrant ssh-config ${SYSTEM}) 
    IDENTITY_FILE=$(echo "${SSHCONFIG}" | grep -o "\/.*${SYSTEM}.*") 
    PORT=$(echo "${SSHCONFIG}" | grep -oE '[0-9]{4,5}') 
    echo "${SYSTEM} ansible_ssh_host=127.0.0.1 ansible_ssh_port=${PORT} ansible_ssh_private_key_file=${IDENTITY_FILE}" >> vagrant.ini 
done 

Następnie użyj ansible-playbook -i=vagrant.ini

Jeśli spróbujesz użyć ~/.ssh/config, musisz dynamicznie tworzyć lub edytować istniejące pozycje, jak porty ssh można zmienić (ze względu na kolizję w Vagrant).