I'm current doing GettingStartedWithDjango Tutorials but I've been furiously stuck/tried many solutions from other questions.
I use 'vagrant up' in the terminal and everything works ok. I can use 'vagrant halt' and do 'vagrant up' without a problem.
But once I 'vagrant ssh' and install postinstall.sh, my problem arises. I vagrant halt and and vagrant up but it comes with the following errors.
Bringing machine 'default' up with 'virtualbox' provider...
==> 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: 8000 => 8888 (adapter 1)
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: Warning: Connection timeout. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
Here is the debug info:
INFO ssh: Attempting SSH connection...
INFO ssh: Attempting to connect to SSH...
INFO ssh: - Host: 127.0.0.1
INFO ssh: - Port: 2222
INFO ssh: - Username: vagrant
INFO ssh: - Password? false
INFO ssh: - Key Path: ["/Users/kennyh/Desktop/GSWD/.vagrant/machines/default/virtualbox/private_key"]
INFO ssh: SSH not ready: #<Vagrant::Errors::SSHAuthenticationFailed: SSH authentication failed! This is typically caused by the public/private
keypair for the SSH user not being properly set on the guest VM. Please
verify that the guest VM is setup with the proper public key, and that
the private key path for Vagrant is setup properly as well.>
Tried using PermitRootLogin without-password.. not sure if you're suppose to unhash it? (tried both anyway) still doesn't work.File was etc/sshd.config
# Authentication:
#LoginGraceTime 2m
PermitRootLogin without-password
#StrictModes yes
#MaxAuthTries 6
#MaxSessions 10
Related
I have a vagrant installed on Windows7 PC. I have jenkins, puppet other stuff installed on my centos7 vagrant box. When I do vagrant reload
==> default: Attempting graceful shutdown of VM...
==> 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: 8082 (guest) => 8080 (host) (adapter 1)
default: 22 (guest) => 2222 (host) (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: Warning: Remote connection disconnect. Retrying...
==> default: Machine booted and ready!
GuestAdditions 5.0.12 running --- OK.
==> default: Checking for guest additions in VM...
==> default: Mounting shared folders...
default: /vagrant => C:/vagrant/projects/jenkins
default: /vagrant_data => C:/Devops
==> default: Machine already provisioned. Run `vagrant provision` or use the `-
provision`
==> default: flag to force provisioning. Provisioners marked to run always will
still run.
Now when I do curl -v
C:\>curl -v http://127.0.0.1:8082
* Rebuilt URL to: http://127.0.0.1:8082/
* timeout on name lookup is not supported
* Trying 127.0.0.1...
* connect to 127.0.0.1 port 8082 failed: Connection refused
* Failed to connect to 127.0.0.1 port 8082: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 127.0.0.1 port 8082: Connection refused
Needless to say http://127.0.0.1:8082 doesnt fetch anything in the browser wither. What am I missing? BTW my vagrant and virtual box 5 is running on Windows7.
Thanks in advance
R
I googling for some days and i do not find any solution to solve my problem.
I pretty sure, This problem not from VT-x because I using bento/ubuntu-14.04-i386 on Windows 8.1 (I guess my CPU allow to use 32bit as guest but 64bit dont C2D E7200)
I clone github repo from laravel/settler and replace config.vm.box = 'bento/ubuntu-14.04' into config.vm.box = 'bento/ubuntu-14.04-i386' on Vagrantfile
And start vagrant with vagrant up and i get this
λ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'bento/ubuntu-14.04-i386'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'bento/ubuntu-14.04-i386' is up to date...
==> default: Setting the name of the VM: settler_default_1446635664316_42330
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
==> default: Forwarding ports...
default: 80 => 8000 (adapter 1)
default: 3306 => 33060 (adapter 1)
default: 5432 => 54320 (adapter 1)
default: 35729 => 35729 (adapter 1)
default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> 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: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: Connection timeout. Retrying...
default: Warning: 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.
vagrant ssh-config
Host default
HostName 127.0.0.1
User vagrant
Port 2222
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
PasswordAuthentication no
IdentityFile C:/Users/Jame/.vagrant.d/insecure_private_key
IdentitiesOnly yes
LogLevel FATAL
vagrant global-status
id name provider state directory
------------------------------------------------------------------------------------------
87ba96c default virtualbox running C:/Users/Jame/Dropbox/Private/myscript/config/settler
The above shows information about all known Vagrant environments
on this machine. This data is cached and may not be completely
up-to-date. To interact with any of the machines, you can go to
that directory and run Vagrant, or you can use the ID directly
with Vagrant commands from any directory. For example:
"vagrant destroy 1a2b3c4d"
and GUI is
Please help, Thank :)
This might have various reasons and it's mostly about private / public keys. You can follow these step to troubleshoot:
1) First of all try if you can ssh with password to make sure that it's about keys. If you can't, then you should first find the reason for that and step 3 would be helpful in that case too.
2) Second thing to do is to find out which private key vagrant is using.
Run vagrant ssh-config and check IdentityFile, in your case this is the default insecure_private_key provided by vagrant.
3) Now run vagrant ssh -- -v which will show you the details of ssh progress, double check the private key that is used. If you see smt. like this at the end you can be sure that server cannot match your public key and that's the problem:
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /Users/ozan/.vagrant.d/insecure_private_key
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password
vagrant#127.0.0.1's password:
debug1: Authentications that can continue: publickey,password
Permission denied, please try again.
vagrant#127.0.0.1's password:
4) ssh your guest with password and check if the public key is ok. You should check the permissions of the ~/.ssh directory and the /.ssh/authorized_keys file. They must be 755 (drwx------) and 600 (-rw-------) respectively and they must be owned by vagrant user.
5) Check that the public key matches your private key. To do so generate the public key from private key like ssh-keygen -f ~/.vagrant.d/insecure_private_key -y on your host and compare it with the one in ~/.ssh/authorized_keys
Also make sure that the keys is in the ~/.ssh/authorized_keys are on a single line, if you do smt. like copy paste it can happen that newline characters are inserted which will obviously break the public key.
And here are some notes about vagrant and homestead which would help:
Normally vagrant replaces this insecure_private_key with some secure one and adjusts everything at startup or halt if config.ssh.insert_key is set totrue in you configuration (which is the default in the latest version 1.7.4). So you might see some path under your .vagrant directory for the IdentityFile.
The problem in my case was, you can define which private key to use in your Homestead.yaml normally, however homestead didn't respect the custom keys for some reason, and vagrant didn't replace the insecure key too...
So I basically generated and copied the public key of the private key that is listed as IdentityFile and put it into authorized_keys which did solve the issue.
After fixing the public key I realized that vagrant replaced the insecure_private_key with some secure one successfuly...
Hey I have been trying to get my homestead running but I keep getting to the error:
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'laravel/homestead' is up to date...
==> 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: Adapter 2: hostonly
==> default: Forwarding ports...
default: 80 => 8000 (adapter 1)
default: 443 => 44300 (adapter 1)
default: 3306 => 33060 (adapter 1)
default: 5432 => 54320 (adapter 1)
default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> 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: Warning: Connection refused. Retrying...
default: Warning: Connection refused. Retrying...
default: Warning: Connection refused. Retrying...
I am running windows 10 and Virtual box 5.0.4
The error is happening right after the line 'default: SSH auth method: private key' and presents a connection refused error, so I assume it can be related to your ssh keys. Did you check if your ssh keys are set properly?
ssh-keygen -t rsa -C "you#homestead"
Try running this again and set your public and private key paths in the homestead.yaml file (make sure it points to the file properly) then try again.
If the problem persists show us your homestead.yaml file so we can try to help better :) I hope I could be of help
First of all I know this is a duplicate issue but I battled with this issue for about 20 hours as none of other questions's answers were working for me. This is Mac OS X specific question and answer. Virtual provider was VirtualBox 4.3 and 5.0. Vagrant versions 1.7.1 and 1.7.4
This SSH authentication failure kept on happening. If I waited or exited the process I could "vagrant ssh" in without problems, using default password "vagrant". But because this SSH failure happened, it meant that the after boot -scripts were not executed either.
vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'laravel/homestead'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'laravel/homestead' is up to date...
==> default: Setting the name of the VM: homestead
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
default: Adapter 1: nat
default: Adapter 2: hostonly
==> default: Forwarding ports...
default: 80 => 8000 (adapter 1)
default: 443 => 44300 (adapter 1)
default: 3306 => 33060 (adapter 1)
default: 5432 => 54320 (adapter 1)
default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> 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: Warning: Connection timeout. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. 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.
Vagrant 1.7 has this default config set to true: config.ssh.insert_key
Vagrant will automatically insert an keypair to use for SSH, replacing the default Vagrant's insecure key inside the machine if detected. link to Vagrant SSH settings
When after vagrant up I did vagrant ssh-config I could see that the private key path was ~/.vagrant.d/insecure_key – but that key was not copied to inside VM either.
The problem was in that I had somehow messed up my OS X's SSH config. This was apparent when I ran command ssh-add -l to list loaded keys in SSH agent. There was two different keys with the same path! However I cannot confirm this was the main reason for the problem as it had persisted for several days and during which I had made a few reboots.
I made a backup of .ssh folder and copied old config lines and files one by one. Another thing I did was to remove this ill-advised tip to add this line in ~/.ssh/config
Host *
ForwardAgent yes
This practice is strongly recommended against by Github:
Warning: You may be tempted to use a wildcard like Host * to just apply this setting to all SSH connections. That's not really a good idea, as you'd be sharing your local SSH keys with every server you SSH into. They won't have direct access to the keys, but they will be able to use them as you while the connection is established. You should only add servers you trust and that you intend to use with agent forwarding.
Before doing these steps I emptied ~/.vagrant.d folder to make sure I had no previously set up global configs in play. You could also uninstall Vagrant with their uninstall script and then reinstall.
Rebooted. Then I created a new SSH key.
Then vagrant provision or vagrant destroy && vagrant up. This is how I finally got this problem solved!
My solution was while Vagrant was displaying 'default: Warning: Authentication failure. Retrying...'
On my local machine grab the public ssh key and stick it into ~/.ssh/authorized_keys inside vagrant. Which allowed vagrant to ssh into the box seamlessly and continue on provisioning in my case. Wish I knew what caused the hang though. (I also deleted all traces of existing .vagrant and .vagrant.d folders before issuing vagrant up.)
cat ~/.ssh/id_rsa.pub
vagrant ssh
echo 'your-public key' >> ~/.ssh/authorized_keys (or paste it in by hand so you don't accidentally delete any existing keys)
When I run vagrant up, I get:
D:\GitHub\website\rails-dev-box>vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'ubuntu/trusty32' is up to date...
==> 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: 3000 => 1234 (adapter 1)
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: Warning: Connection timeout. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
This warning will be for ever ..
What I've noticed is that if I started the VM manually ( without vagrant ) it will work without any delay, but only If I enabled Adapter 2 at VM settings like this:
How can I enable Adapter 2 of VM when using vagrant up ?
EDIT
Vagrantfile is:
# -*- mode: ruby -*-
# vi: set ft=ruby :
Vagrant::Config.run do |config|
# config.vm.network :hostonly, "192.168.50.4"
end
Vagrant.configure('2') do |config|
config.vm.box = 'ubuntu/trusty32'
config.vm.hostname = 'rails-dev-box'
# config.vm.synced_folder ".", "/vagrant/web" #, type: "nfs"
config.vm.provider :virtualbox do |vb|
vb.gui = true
end
config.vm.boot_timeout = 120
# config.winnfsd.uid = 1
# config.winnfsd.gid = 1
config.vm.network :forwarded_port, guest: 3000, host: 1234
config.vm.provision :shell, path: 'bootstrap.sh', keep_color: true
end
For me it turned out that patience was the answer.
I was getting the message (I got it 12 times) but I waited a couple of minutes and then it succeeded.
When you say "this warning will be for ever .." How long did you wait?
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'phusion/ubuntu-14.04-amd64' is up to date...
==> 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: Adapter 2: hostonly
default: Adapter 3: hostonly
default: Adapter 4: hostonly
==> default: Forwarding ports...
default: 3000 => 3334 (adapter 1)
default: 1080 => 1082 (adapter 1)
default: 22 => 2222 (adapter 1)
==> default: Running 'pre-boot' VM customizations...
==> 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: Warning: Connection timeout. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
default: Warning: Remote connection disconnect. Retrying...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
==> default: Configuring and enabling network interfaces...
==> default: Exporting NFS shared folders...
==> default: Preparing to edit /etc/exports. Administrator privileges will be required...
Password:
==> default: Mounting NFS shared folders...
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: to force provisioning. Provisioners marked to run always will still run.
==> default: Running provisioner: shell...
default: Running: inline script
==> default: stdin: is not a tty
==> default: stop: Unknown instance:
==> default: mongod start/running, process 8424
Not really a solution per-say, but I have found that when I timed out after getting that message ~20 times that I could vagrant halt the machine (which forces it as there is no ssh connection that can be made), ran vagrant up, it worked only giving me the warning twice.
So... turn it off and on again? So stupid but does seem to work untill there's an actual solution.