Błędny błąd: limit czasu połączenia. Ponowna próba

Mam serwer z Ubuntu 12.04, Virtualbox 4.3 i Vagrant 1.5.1. Próbuję użyć tego pola http://puppet-vagrant-boxes.puppetlabs.com/centos-64-x64-vbox4210.box jednak bezskutecznie. Kiedy uruchamiam „włóczęgę”, pojawia się następujący komunikat:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'centos-64-x64-vbox4210'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: rafael_default_1396403974194_51967
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 => 2222 (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
    default: Error: Connection timeout. Retrying...
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.

If you look above, you should be able to see the error(s) that
Vagrant had when attempting to connect to the machine. These errors
are usually good hints as to what may be wrong.

If you're using a custom box, make sure that networking is properly
working and you're able to connect to the machine. It is a common
problem that networking isn't setup properly in these boxes.
Verify that authentication configurations are also setup properly,
as well.

If the box appears to be booting properly, you may want to increase
the timeout ("config.vm.boot_timeout") value.

To jest mój plik Vagrant

# Vagrantfile API/syntax version. Don't touch unless you know what you're doing!
VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  # All Vagrant configuration is done here. The most common configuration
  # options are documented and commented below. For a complete reference,
  # please see the online documentation at vagrantup.com.

  # Every Vagrant virtual environment requires a box to build off of.
  config.vm.box = "centos-64-x64-vbox4210"
  config.vm.boot_timeout = 600
  # The url from where the 'config.vm.box' box will be fetched if it
  # doesn't already exist on the user's system.
  # config.vm.box_url = "http://domain.com/path/to/above.box"

  # Create a forwarded port mapping which allows access to a specific port
  # within the machine from a port on the host machine. In the example below,
  # accessing "localhost:8080" will access port 80 on the guest machine.
  # config.vm.network "forwarded_port", guest: 80, host: 8080

  # Create a private network, which allows host-only access to the machine
  # using a specific IP.
  # config.vm.network "private_network", ip: "192.168.33.10"

  # Create a public network, which generally matched to bridged network.
  # Bridged networks make the machine appear as another physical device on
  # your network.
  # config.vm.network "public_network"

  # If true, then any SSH connections made will enable agent forwarding.
  # Default value: false
  # config.ssh.forward_agent = true

  # Share an additional folder to the guest VM. The first argument is
  # the path on the host to the actual folder. The second argument is
  # the path on the guest to mount the folder. And the optional third
  # argument is a set of non-required options.
  # config.vm.synced_folder "../data", "/vagrant_data"
  # Enable provisioning with chef server, specifying the chef server URL,
  # and the path to the validation key (relative to this Vagrantfile).
  #
  # The Opscode Platform uses HTTPS. Substitute your organization for
  # ORGNAME in the URL and validation key.
  #
  # If you have your own Chef Server, use the appropriate URL, which may be
  # HTTP instead of HTTPS depending on your configuration. Also change the
  # validation key to validation.pem.
  #
  # config.vm.provision "chef_client" do |chef|
  #   chef.chef_server_url = "https://api.opscode.com/organizations/ORGNAME"    
  #   chef.validation_key_path = "ORGNAME-validator.pem"
  # end
  #
  # If you're using the Opscode platform, your validator client is
  # ORGNAME-validator, replacing ORGNAME with your organization name.
  #
  # If you have your own Chef Server, the default validation client name is
  # chef-validator, unless you changed the configuration.
  #
  #   chef.validation_client_name = "ORGNAME-validator"
end

mój serwer nie ma interfejsu graficznego Jak mogę to naprawić? Dzięki.

Najpierw spróbuj: sprawdzić, jaki błędny klucz prywatny znajduje się w konfiguracji komputera

$ vagrant ssh-config

Przykład:

$ vagrant ssh-config
Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile C:/Users/konst/.vagrant.d/insecure_private_key
  IdentitiesOnly yes
  LogLevel FATAL

Vagrant SSH Config Docs

Po drugie, należy: Zmiana zawartości pliku insecure_private_key z treścią Yorn własny system klucza prywatnego

spróbuj włączyć GUI wirtualnego boxu, jak opisano w tym poście Vagrant utknął limit czasu połączenia i postępuj zgodnie z instrukcjami w komentarzach.

jeśli to nie działa spróbuj dodać tę modyfikację do swojego pliku Vagrant:

utwórz plik o nazwie „script.sh”, który zawiera następujące polecenia:

mkdir /home/vagrant/.ssh
wget --no-check-certificate -O authorized_keys 'https://github.com/mitchellh/vagrant/raw/master/keys/vagrant.pub'
mv authorized_keys /home/vagrant/.ssh
chown -R vagrant /home/vagrant/.ssh
chmod -R go-rwsx /home/vagrant/.ssh

następnie dodaj to do swojego pliku Vagrantfile:

  # running script shell
    config.vm.provision :shell, :path => "script.sh"

Limit czasu połączenia SSH podczas fazy rozruchu może nastąpić z różnych powodów, takich jak:

• system czeka na interakcję użytkownika (np. partycja udostępniania nie jest gotowa ),
• sshd błędna konfiguracja,
• błędna konfiguracja zapory (jeśli nie jest lokalna),
• niedopasowanie twojego klucza prywatnego,
• config.vm.boot_timeout okres czasu jest za krótki (który jest w porządku),
• upewnij się, że wirtualizacja jest włączona w systemie BIOS.

Aby debugować problem, uruchom go jako:

VAGRANT_LOG=debug vagrant up

Jeśli nie ma nic oczywistego, spróbuj połączyć się z nim z innego terminala vagrant sshprzez:

vagrant ssh-config > vagrant-ssh; ssh -F vagrant-ssh default

Jeśli SSH nadal nie działa, uruchom go ponownie z GUI (np config.gui = true.).

Jeśli nie, sprawdź uruchomione procesy (np. Przez vagrant ssh -c 'pstree -a':) lub zweryfikuj swoje sshd_config.

Jeśli jest to maszyna wirtualna jednorazowego użytku, zawsze możesz destroyto upzrobić ponownie. Zastanów się również nad aktualizacją Vagrant i Virtualbox.

Spróbuj otworzyć port 22 w zaporze.

Za pomocą Oracle VM VirtualBox Manager uruchom maszynę wirtualną bezpośrednio lub

dodaj to do swojego pliku Vagrantfile

config.vm.provider :virtualbox do |vb|
  vb.gui = true
end

i uruchom „włóczęgę”

zaloguj się przy użyciu domyślnych poświadczeń Vagrant

user: vagrant
pass: vagrant

dodaj regułę zapory ogniowej

sudo ufw allow 22

Właśnie rozwiązałem podobny problem.

Problem : Upłynął limit czasu polecenia logowania do środowiska programistycznego gościa vagrant ssh. Rutynowo działa dobrze na innym komputerze hosta.

Kroki debugowania:

1. W pliku Vagrantfile włączyłem GUI Virtualbox (jak zalecono w innej odpowiedzi), aby zobaczyć, co spowodowało przekroczenie limitu czasu. Ubuntu poprosił o login i hasło, czego nie powinien, ponieważ zamiast tego powinien używać klucza ssh.

2. Zamiast uruchamiać vagrant ssh, wielokrotnie uruchamiałem równoważne polecenie ssh, dodając i usuwając różne opcje ssh. Jeden z komunikatów o błędzie przekroczenia limitu czasu brzmiał „nie można się zalogować do [example.com]”… co nie ma sensu, ponieważ ten problem nie ma nic wspólnego z [example.com].

3. To skłoniło mnie do spojrzenia na .ssh / config, gdzie [example.com] może mieć jakieś znaczenie.

Główna przyczyna : W .ssh / config przypadkowo pojawił się wpis bez Hostustawienia. Dlatego stosował tę regułę konfiguracji do wszystkich wywołań ssh, w tym vagrant ssh(który jest tylko skrótem dla dłuższego polecenia ssh).

Rozwiązanie : Upewnij się, że każdy wpis .ssh / config jest Hostustawiony.

Spróbuj wygenerować insecure_private_key

Rozwiązałem to, usuwając insecure_private_keyznajdujący się pod~/.vagrant.d

może przyczyną jest to, że insecure_private_keyplik jest stary

Miałem ten sam problem. Usunąłem wszystko z SystemPrefereces-> Bezpieczeństwo-> Firewall i usunąłem wszystkie usługi z SystemPreferences-> Shared. Następnie ponownie włączyłem zdalne logowanie. To rozwiązało problem w moim przypadku. Jeśli to nie rozwiąże problemu, możesz odwiedzić tę stronę i sprawdzić to sam. (ServerFaqs)

Wystąpił podobny problem. Oto co zrobiłem.

• Włączona wirtualizacja w systemie BIOS
• Biegł ssh-add ~/.vagrant.d/insecure_private_key
• Dodano config.vm.boot_timeout = 600do mojego~/Homestead/Vagrantfile

Teraz działa dobrze.

Musisz mieć możliwość GUI. Usuń komentarz z tych linii w swoim Vagrantpliku:

config.vm.provider :virtualbox do |vb|
  vb.gui = true
end

Po wyłączeniu urządzenia i ponownym uruchomieniu:

vagrant halt
vagrant up

Jak naprawiłem:

w vagrantfile włącz / usuń komentarz z poniższych ...

config.vm.network "private_network", ip: "192.168.33.10"
...
config.vm.network "public_network"

Ten problem może być spowodowany wieloma czynnikami, w tym sytuacją, w której okno maszyny wirtualnej zawiesza się i oczekuje na odpowiedź użytkownika. Jednak powszechnym problemem było niedopasowanie klucza prywatnego i klucza publicznego. Aby rozwiązać ten problem, musisz dostarczyć plik klucza prywatnego na komputerze hosta, który jest zgodny z plikiem klucza publicznego w polu maszyny wirtualnej. Na naszym blogu zamieściłem tutaj rozwiązanie z 3 opcjonalnymi podejściami ...

http://www.productiveminds.com/blog/vagrant-ssh-authentication-how-to-successfully-login-into-vm-box-using-vagrant-up/

To działa dla mnie:

1. zaloguj się za pomocą: gui przez login / pass: vagrant / vagrant
2. zmodyfikuj /etc/rc.localplik, aby zawierał linię sh /etc/init.d/networking restarttuż przedexit 0
3. wyłącz: gui
4. włóczęga się lub włóczęga przeładowuje

https://github.com/mitchellh/vagrant/issues/391#issuecomment-2078383

Mam ten sam problem i to moje pierwsze doświadczenie z włóczęgą.

Udało mi się „rozwiązać” problem za pomocą sieci publicznej zamiast prywatnej

config.vm.network "public_network", ip: "192.168.3.175"

Zastąp 192.168.3.175adres IP należący do klasy sieci.

Chciałbym jednak zrozumieć, co jest nie tak z siecią prywatną ...

config.vm.boot_timeout- Czas w sekundach, przez jaki Vagrant będzie czekać na uruchomienie komputera i będzie dostępny. Domyślnie jest to 300 sekund.

Zwiększałbym to, dopóki nie będziesz w stanie pochwalić się SSH.