Trellis: failed SSH connection to box after `vagrant up`

[timiyay]

I recently updated the roots/bedrock Vagrant box to 0.3.0, and can't get the box to load up. After running vagrant up and booting, the client fails to connect via SSH. Instead, the connection times out and retries repeatedly:

==> 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...

I'm running Vagrant 1.6.5

[swalkinshaw]

Did you update this repo/the playbook itself? The updated 0.3.0 Vagrant box is actually the same as 0.2.0 (just wanted to keep versions in sync) so nothing changed with that.

My first thought is something else is going on although I'm not sure what.

[nathanielks]

I've had the same thing happen to me as well. I believe I vagrant halt'd other vm's that were running and retried and it worked.

[timiyay]

This issue seems to have resolved itself, though I have no idea why. I just vagrant destroyed my bedrock box, ignored it for a couple of days, then did vagrant up, and I'm back in action.

I'll close this off...

[nathanielks]

If remember correctly, it has to do with ip/portforwarding. Vagrant issue more than a bedrock-ansible one. Glad it's working now!—
Sent from Mailbox

On Wed, Sep 10, 2014 at 7:40 PM, timiyay [email protected] wrote:

This issue seems to have resolved itself, though I have no idea why. I just vagrant destroyed my bedrock box, ignored it for a couple of days, then did vagrant up, and I'm back in action.

I'll close this off...

Reply to this email directly or view it on GitHub:
https://github.com/roots/bedrock-ansible/issues/46#issuecomment-55204871

[intelligence]

I've tried all of the above with no resolution. Also tried switching from the bedrock box to regular trusty64, no luck with that either.

Also tried this: http://stackoverflow.com/a/23554973/562747

I just updated Vagrant to latest version, thought that might be it, but my old box still works.

Would be really helpful if you could figure out what you did @nathanielks

[nathanielks]

@intelligence It has to do with how Vagrant manages multiple boxes running at the same time. Whenever there's an ip clash ( ie, more than one box ), it has to change the ports it uses to ssh into the server. Bringing down other running boxes and then bringing mine up cleared the issue for me. Might also want to open up VirtualBox and see if there are stray machines that were created but not halted/destroyed in the past. Could be your issue there. Hope this helps!

[intelligence]

Unfortunately not, I've halted all machines.. Really annoying this.

[nathanielks]

@intelligence yuck. sorry =\

[intelligence]

As I can get in manually via ssh -p 2222 vagrant@localhost should I just run the playbook on it's own or will it fail due to stuff not getting provisioned as it should via the initial vagrant up?

vagrant-hostsupdater missing, please install the plugin:
vagrant plugin install vagrant-hostsupdater
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Checking if box 'roots/bedrock' 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: 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: 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.

[nathanielks]

in whatever directory you have this project living in, what does your .vagrant/provisioners/ansible/inventory/vagrant_ansible_inventory file look like?

[intelligence]

In my bedrock-ansible folder I have a .vagrant folder, it's only subfolder is "machines", is this the folder you mean, but that it lacks the provisioners subfolder?

[nathanielks]

Aye, that's the right one. Have you ever been able to successfully provision this machine, or is this a vanilla one?

—
Sent from Mailbox

On Mon, Nov 17, 2014 at 3:49 PM, intelligence [email protected]
wrote:

In my bedrock-ansible folder I have a .vagrant folder, it's only subfolder is "machines", is this the folder you mean, but that it lacks the provisioners subfolder?

Reply to this email directly or view it on GitHub:
https://github.com/roots/bedrock-ansible/issues/46#issuecomment-63382415

[intelligence]

Nope, it's vanilla. First time trying out bedrock-ansible, last project I worked on I used vagrant with bedrock setup manually, the ansible playbook wasn't finished yet.

Re the SSH trouble, here's a SO thread about what I've tried: http://stackoverflow.com/questions/26978426/vagrant-warning-authentication-failure-retrying

[fullyint]

@intelligence If you haven't done it already, you could get more info by running VAGRANT_LOG=info vagrant up or VAGRANT_LOG=debug vagrant up then search for SSH auth method: private key.

Also, although it probably won't solve your SSH trouble, see #96. Your Vagrantfile at SO shows bedrock_path = '../bedrock'. I think you'll need to rename your bedrock folder to a hostname like example.dev and change bedrock_path = '../example.dev' for provisioning to succeed (after you resolve the SSH problem above).

[intelligence]

Ah, nice heads up.

config.vm.network :private_network, ip: '192.168.50.5'
config.vm.hostname = 'zahnarzt-altena.dev'
bedrock_path = '../bedrock'
bedrock_path_server = '/srv/www/zahnarzt-altena.de/current'

Should work, right? (Please note it's a german TLD, not dev misspelled ;-))

[fullyint]

I think that should work, so long as you set site_name: zahnarzt-altena.de in the group_vars/development file (see how site_name is used in places like roles/wordpress-sites/tasks/directories.yml and elsewhere).

Alternatively, you could just leave bedrock_path_server as the new default introduced in #97 since the time of my last comment (bedrock_path_server = File.join('/srv/www', config.vm.hostname, 'current')). However, I'm realizing now that this default requires site_name (in group_vars/development) and config.vm.hostname (in Vagrantfile) to have the same value (e.g., zahnarzt-altena.dev in your case).

[intelligence]

Thanks!

Regarding authentication failure, anything I can check up on with the ssh keys that might be in disorder (although they should not be I suppose).

authorized_keys in guest should have the content of id_rsa.pub on the host?

[fullyint]

I'm not that familiar with SSH matters, but here's what comes to mind.

1) You asked:

authorized_keys in guest should have the content of id_rsa.pub on the host?

Vagrant's key pair. I'm pretty sure authorized_keys in the vm just needs the vagrant insecure public key, not the host's id_rsa.pub. When you vagrant ssh in to the vm, then run less /home/vagrant/.ssh/authorized_keys, I think you should see the same key as https://raw.githubusercontent.com/mitchellh/vagrant/master/keys/vagrant.pub. If you don't see that key, I don't know how vagrant ssh would even work. But anyway, here are ideas for missing public key.

2) Have you run VAGRANT_LOG=debug vagrant up yet? I'm guessing you'll find the most relevant portion of the resulting log by searching for the final instance of beginning authentication ofvagrant'and inspect the next 20-odd lines, probably ending withall authorization methods failed (tried none, publickey, password)`. Consider sharing it here and maybe someone will make sense of it.

Here's my log after SSH auth fails due to an intentionally corrupted insecure_private_key:

# LOG: When SSH Auth Fails (due to corrupted insecure_private_key)...
...
D, [date] DEBUG -- net.ssh.authentication.session[806c98fc]: beginning authentication of `vagrant'
D, [date] DEBUG -- tcpsocket[80acc9cc]: queueing packet nr 4 type 5 len 28
D, [date] DEBUG -- tcpsocket[80acc9cc]: sent 52 bytes
D, [date] DEBUG -- tcpsocket[80acc9cc]: read 52 bytes
D, [date] DEBUG -- tcpsocket[80acc9cc]: received packet nr 4 type 6 len 28
D, [date] DEBUG -- net.ssh.authentication.session[806c98fc]: trying none
D, [date] DEBUG -- tcpsocket[80acc9cc]: queueing packet nr 5 type 50 len 44
D, [date] DEBUG -- tcpsocket[80acc9cc]: sent 68 bytes
D, [date] DEBUG -- tcpsocket[80acc9cc]: read 68 bytes
D, [date] DEBUG -- tcpsocket[80acc9cc]: received packet nr 5 type 51 len 44
D, [date] DEBUG -- net.ssh.authentication.session[806c98fc]: allowed methods: publickey,password
D, [date] DEBUG -- net.ssh.authentication.methods.none[806cdeac]: none failed
D, [date] DEBUG -- net.ssh.authentication.session[806c98fc]: trying publickey
E, [date] ERROR -- net.ssh.authentication.key_manager[806c8060]: could not load private key file `/Users/fullyint/.vagrant.d/insecure_private_key': ArgumentError (Could not parse PKey: no start line)
D, [date] DEBUG -- net.ssh.authentication.agent[806d1818]: connecting to ssh-agent
D, [date] DEBUG -- net.ssh.authentication.agent[806d1818]: sending agent request 1 len 61
D, [date] DEBUG -- net.ssh.authentication.agent[806d1818]: received agent packet 2 len 5
D, [date] DEBUG -- net.ssh.authentication.agent[806d1818]: sending agent request 11 len 0
D, [date] DEBUG -- net.ssh.authentication.agent[806d1818]: received agent packet 12 len 317
D, [date] DEBUG -- net.ssh.authentication.session[806c98fc]: trying password
E, [date] ERROR -- net.ssh.authentication.session[806c98fc]: all authorization methods failed (tried none, publickey, password)

For comparison, here's my log when SSH succeeds:

# LOG: When SSH Auth Succeeds...
...
D, [date] DEBUG -- net.ssh.authentication.session[80669358]: beginning authentication of `vagrant'
D, [date] DEBUG -- tcpsocket[8062c4a8]: queueing packet nr 4 type 5 len 28
D, [date] DEBUG -- tcpsocket[8062c4a8]: sent 52 bytes
D, [date] DEBUG -- tcpsocket[8062c4a8]: read 52 bytes
D, [date] DEBUG -- tcpsocket[8062c4a8]: received packet nr 4 type 6 len 28
D, [date] DEBUG -- net.ssh.authentication.session[80669358]: trying none
D, [date] DEBUG -- tcpsocket[8062c4a8]: queueing packet nr 5 type 50 len 44
D, [date] DEBUG -- tcpsocket[8062c4a8]: sent 68 bytes
D, [date] DEBUG -- tcpsocket[8062c4a8]: read 68 bytes
D, [date] DEBUG -- tcpsocket[8062c4a8]: received packet nr 5 type 51 len 44
D, [date] DEBUG -- net.ssh.authentication.session[80669358]: allowed methods: publickey,password
D, [date] DEBUG -- net.ssh.authentication.methods.none[8067a090]: none failed
D, [date] DEBUG -- net.ssh.authentication.session[80669358]: trying publickey
D, [date] DEBUG -- net.ssh.authentication.agent[806760bc]: connecting to ssh-agent
D, [date] DEBUG -- net.ssh.authentication.agent[806760bc]: sending agent request 1 len 61
D, [date] DEBUG -- net.ssh.authentication.agent[806760bc]: received agent packet 2 len 5
D, [date] DEBUG -- net.ssh.authentication.agent[806760bc]: sending agent request 11 len 0
D, [date] DEBUG -- net.ssh.authentication.agent[806760bc]: received agent packet 12 len 317
D, [date] DEBUG -- net.ssh.authentication.methods.publickey[806763c8]: trying publickey (d:3b:b8:2e:85:04:06:e9:ab:ff:a8:0a:c0:04:6e:d6)
D, [date] DEBUG -- tcpsocket[8062c4a8]: queueing packet nr 6 type 50 len 348
D, [date] DEBUG -- tcpsocket[8062c4a8]: sent 372 bytes
D, [date] DEBUG -- tcpsocket[8062c4a8]: read 324 bytes
D, [date] DEBUG -- tcpsocket[8062c4a8]: received packet nr 6 type 60 len 300
D, [date] DEBUG -- tcpsocket[8062c4a8]: queueing packet nr 7 type 50 len 620
D, [date] DEBUG -- tcpsocket[8062c4a8]: sent 644 bytes
D, [date] DEBUG -- tcpsocket[8062c4a8]: read 36 bytes
D, [date] DEBUG -- tcpsocket[8062c4a8]: received packet nr 7 type 52 len 12
D, [date] DEBUG -- net.ssh.authentication.methods.publickey[806763c8]: publickey succeeded (dd:3b:b8:2e:85:04:06:e9:ab:ff:a8:0a:c0:04:6e:d6)

3) Might you have anything in your ~/.ssh/config file that would be interfering?

4) Of course, if you haven't do so already, you might completely uninstall and reinstall Vagrant.

[intelligence]

Thanks for your thorough steps!

1) Just went through a diff checker, the keys are identical.
2) Log don't seem to tell me much, besides it's failing

DEBUG virtualbox_4_3:   - [1, "ssh", 2222, 22]
DEBUG ssh: Checking key permissions: /Users/intelligence/.vagrant.d/insecure_private_key
 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/intelligence/.vagrant.d/insecure_private_key"]
DEBUG ssh: == Net-SSH connection debug-level log START ==
DEBUG ssh: D, [2014-11-19T10:44:41.387605 #43783] DEBUG -- net.ssh.transport.session[808a0b44]: establishing connection to 127.0.0.1:2222
D, [2014-11-19T10:44:41.389095 #43783] DEBUG -- net.ssh.transport.session[808a0b44]: connection established
I, [2014-11-19T10:44:41.389868 #43783]  INFO -- net.ssh.transport.server_version[808a12b0]: negotiating protocol version
D, [2014-11-19T10:44:41.410979 #43783] DEBUG -- net.ssh.transport.server_version[808a12b0]: remote is SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2
D, [2014-11-19T10:44:41.411277 #43783] DEBUG -- net.ssh.transport.server_version[808a12b0]: local is SSH-2.0-Ruby/Net::SSH_2.9.1 universal.x86_64-darwin12.5.0
D, [2014-11-19T10:44:41.415391 #43783] DEBUG -- tcpsocket[808a1c74]: read 1648 bytes
D, [2014-11-19T10:44:41.416179 #43783] DEBUG -- tcpsocket[808a1c74]: received packet nr 0 type 20 len 1644
I, [2014-11-19T10:44:41.416735 #43783]  INFO -- net.ssh.transport.algorithms[808a5eb4]: got KEXINIT from server
I, [2014-11-19T10:44:41.417995 #43783]  INFO -- net.ssh.transport.algorithms[808a5eb4]: sending KEXINIT
D, [2014-11-19T10:44:41.419187 #43783] DEBUG -- tcpsocket[808a1c74]: queueing packet nr 0 type 20 len 2020
D, [2014-11-19T10:44:41.419527 #43783] DEBUG -- tcpsocket[808a1c74]: sent 2024 bytes
I, [2014-11-19T10:44:41.419710 #43783]  INFO -- net.ssh.transport.algorithms[808a5eb4]: negotiating algorithms
D, [2014-11-19T10:44:41.420342 #43783] DEBUG -- net.ssh.transport.algorithms[808a5eb4]: negotiated:
* kex: diffie-hellman-group-exchange-sha1
* host_key: ssh-rsa
* encryption_server: aes128-cbc
* encryption_client: aes128-cbc
* hmac_client: hmac-sha1
* hmac_server: hmac-sha1
* compression_client: none
* compression_server: none
* language_client: 
* language_server: 
D, [2014-11-19T10:44:41.420512 #43783] DEBUG -- net.ssh.transport.algorithms[808a5eb4]: exchanging keys
D, [2014-11-19T10:44:41.421362 #43783] DEBUG -- tcpsocket[808a1c74]: queueing packet nr 1 type 34 len 20
D, [2014-11-19T10:44:41.421588 #43783] DEBUG -- tcpsocket[808a1c74]: sent 24 bytes
D, [2014-11-19T10:44:41.427700 #43783] DEBUG -- tcpsocket[808a1c74]: read 152 bytes
D, [2014-11-19T10:44:41.428150 #43783] DEBUG -- tcpsocket[808a1c74]: received packet nr 1 type 31 len 148
D, [2014-11-19T10:44:41.433375 #43783] DEBUG -- tcpsocket[808a1c74]: queueing packet nr 2 type 32 len 140
D, [2014-11-19T10:44:41.433610 #43783] DEBUG -- tcpsocket[808a1c74]: sent 144 bytes
D, [2014-11-19T10:44:41.439865 #43783] DEBUG -- tcpsocket[808a1c74]: read 720 bytes
D, [2014-11-19T10:44:41.440195 #43783] DEBUG -- tcpsocket[808a1c74]: received packet nr 2 type 33 len 700
D, [2014-11-19T10:44:41.443724 #43783] DEBUG -- tcpsocket[808a1c74]: queueing packet nr 3 type 21 len 20
D, [2014-11-19T10:44:41.443939 #43783] DEBUG -- tcpsocket[808a1c74]: sent 24 bytes
D, [2014-11-19T10:44:41.444290 #43783] DEBUG -- tcpsocket[808a1c74]: received packet nr 3 type 21 len 12
D, [2014-11-19T10:44:41.445285 #43783] DEBUG -- net.ssh.authentication.session[808c8900]: beginning authentication of vagrant
D, [2014-11-19T10:44:41.445781 #43783] DEBUG -- tcpsocket[808a1c74]: queueing packet nr 4 type 5 len 28
D, [2014-11-19T10:44:41.446026 #43783] DEBUG -- tcpsocket[808a1c74]: sent 52 bytes
D, [2014-11-19T10:44:41.446999 #43783] DEBUG -- tcpsocket[808a1c74]: read 52 bytes
D, [2014-11-19T10:44:41.447305 #43783] DEBUG -- tcpsocket[808a1c74]: received packet nr 4 type 6 len 28
D, [2014-11-19T10:44:41.447607 #43783] DEBUG -- net.ssh.authentication.session[808c8900]: trying none
D, [2014-11-19T10:44:41.447997 #43783] DEBUG -- tcpsocket[808a1c74]: queueing packet nr 5 type 50 len 44
D, [2014-11-19T10:44:41.448164 #43783] DEBUG -- tcpsocket[808a1c74]: sent 68 bytes
D, [2014-11-19T10:44:41.453258 #43783] DEBUG -- tcpsocket[808a1c74]: read 68 bytes
D, [2014-11-19T10:44:41.453648 #43783] DEBUG -- tcpsocket[808a1c74]: received packet nr 5 type 51 len 44
D, [2014-11-19T10:44:41.453971 #43783] DEBUG -- net.ssh.authentication.session[808c8900]: allowed methods: publickey,password
D, [2014-11-19T10:44:41.454231 #43783] DEBUG -- net.ssh.authentication.methods.none[808cce38]: none failed
D, [2014-11-19T10:44:41.454449 #43783] DEBUG -- net.ssh.authentication.session[808c8900]: trying publickey
D, [2014-11-19T10:44:41.455237 #43783] DEBUG -- net.ssh.authentication.agent[808d0bb4]: connecting to ssh-agent
D, [2014-11-19T10:44:41.455623 #43783] DEBUG -- net.ssh.authentication.agent[808d0bb4]: sending agent request 1 len 61
D, [2014-11-19T10:44:41.455983 #43783] DEBUG -- net.ssh.authentication.agent[808d0bb4]: received agent packet 2 len 5
D, [2014-11-19T10:44:41.456159 #43783] DEBUG -- net.ssh.authentication.agent[808d0bb4]: sending agent request 11 len 0
D, [2014-11-19T10:44:41.456431 #43783] DEBUG -- net.ssh.authentication.agent[808d0bb4]: received agent packet 12 len 681
D, [2014-11-19T10:44:41.457544 #43783] DEBUG -- net.ssh.authentication.methods.publickey[808d0e34]: trying publickey (19:8a:49:fa:7c:64:11:3c:61:57:05:1c:ce:85:1c:0f)
D, [2014-11-19T10:44:41.458114 #43783] DEBUG -- tcpsocket[808a1c74]: queueing packet nr 6 type 50 len 348
D, [2014-11-19T10:44:41.458373 #43783] DEBUG -- tcpsocket[808a1c74]: sent 372 bytes
D, [2014-11-19T10:44:41.460564 #43783] DEBUG -- tcpsocket[808a1c74]: read 68 bytes
D, [2014-11-19T10:44:41.460877 #43783] DEBUG -- tcpsocket[808a1c74]: received packet nr 6 type 51 len 44
D, [2014-11-19T10:44:41.461137 #43783] DEBUG -- net.ssh.authentication.session[808c8900]: allowed methods: publickey,password
D, [2014-11-19T10:44:41.461254 #43783] DEBUG -- net.ssh.authentication.session[808c8900]: trying password
E, [2014-11-19T10:44:41.461415 #43783] ERROR -- net.ssh.authentication.session[808c8900]: all authorization methods failed (tried none, publickey, password)

DEBUG ssh: == Net-SSH connection debug-level log END ==
 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.>

3) Content of config is:

Host 127.0.0.1
  StrictHostKeyChecking no
  UserKnownHostsfile=/dev/null
  IdentitiesOnly yes

4) I guess that's what's left to do.

[fullyint]

I'd be inclined to reinstall vagrant at this point. But here are some reactions to the log you posted.

Note. My understanding is that you really do need to use vagrant's public/private key pair "since that is what public boxes use", unless "you make your own custom box with a custom SSH key" (quoting from config.ssh.private_key_path section of Vagrant docs).

1) Comparing the key fingerprint in our logs, google shows mine (dd:3b:b8:2e:85:04:06:e9:ab:ff:a8:0a:c0:04:6e:d6) as associated with the vagrant public key, as expected, but I find no google results for yours. Do you see the fingerprint from your log above (19:8a:49:fa:7c:64:11:3c:61:57:05:1c:ce:85:1c:0f) listed when you run ssh-add -l on your host/mac (listed perhaps for ~/.ssh/id_rsa)? If so, here are some ideas...

2) I assume you've removed config.ssh.private_key_path = "~/.ssh/id_rsa" from your Vagrantfile, right? If present, that would cause ssh to try your personal key instead of vagrant's.

3) It's a long shot, but do you have any environment variables that might cause vagrant to use something other than its typical key pair? You might run printenv to check your environment variables.

4) Your SO thread mentioned that you tried replacing the contents of insecure_private_key with contents from ~/.ssh/id_rsa. Maybe something got messed up in the process of changing insecure_private_key back to its original value. You could just delete the insecure_private_key file -- vagrant should create a new one on the next vagrant up.

5) Considering the "Load Order and Merging" section in the Vagrant docs, maybe you could try adding config.ssh.private_key_path = "~/.vagrant.d/insecure_private_key" to your Vagrantfile. That is the default value, but maybe somehow in your case an override config is being merged in.

6) Otherwise, I don't know if it is an issue that our logs differ occasionally on packet length.

7) Also, it seems like a long shot, but could the missing the backtick and single quote on beginning authentication ofvagrant'` in your log suggest that it is trying a different ssh username than mine?

[intelligence]

And there we have it. As simple as just deleting insecure_private_key.

Wow I feel stupid, but I had a hunch it was a problem created by myself. Thanks for being patient with me, and hopefully somebody else can get something out of this as well :)

[fullyint]

That's great news! I'm glad it worked out.

[alx]

Hi all,

I've got the same kind of issue, and tried every mentionned in this thread without success.
Everything is a fresh install on a debian wheezy.

Could you help me debug this problem ?

In virtualbox GUI, the bedrock virtual machine is running.

Here is a part of the VAGRAND_LOG=debug log :

DEBUG ssh: == Net-SSH connection debug-level log START ==
DEBUG ssh: D, [2015-01-24T00:56:57.428328 #24515] DEBUG -- net.ssh.transport.session[51c44cc]: establishing connection to 127.0.0.1:2222
D, [2015-01-24T00:56:57.429399 #24515] DEBUG -- net.ssh.transport.session[51c44cc]: connection established
I, [2015-01-24T00:56:57.429904 #24515]  INFO -- net.ssh.transport.server_version[51c7f8c]: negotiating protocol version
DEBUG ssh: == Net-SSH connection debug-level log END ==

Here trying with command line :

$ ssh -vvv -p 2222 -i /home/alx/.vagrant.d/insecure_private_key vagrant@localhost 
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 2222.
debug1: connect to address ::1 port 2222: Connection refused
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/alx/.vagrant.d/insecure_private_key" as a RSA1 public key
debug1: identity file /home/alx/.vagrant.d/insecure_private_key type -1
debug1: identity file /home/alx/.vagrant.d/insecure_private_key-cert type -1

Then it hangs...

[nathanielks]

Is this immediately after a provision? Have you ssh'd in a few times before you weren't able to connect?

—
Sent from Mailbox

On Fri, Jan 23, 2015 at 6:14 PM, Alexandre Girard
[email protected] wrote:

Hi all,
I've got the same kind of issue, and tried every mentionned in this thread without success.
Everything is a fresh install on a debian wheezy.
Could you help me debug this problem ?
In virtualbox GUI, the bedrock virtual machine is running.
Here is a part of the VAGRAND_LOG=debug log :

DEBUG ssh: == Net-SSH connection debug-level log START ==
DEBUG ssh: D, [2015-01-24T00:56:57.428328 #24515] DEBUG -- net.ssh.transport.session[51c44cc]: establishing connection to 127.0.0.1:2222
D, [2015-01-24T00:56:57.429399 #24515] DEBUG -- net.ssh.transport.session[51c44cc]: connection established
I, [2015-01-24T00:56:57.429904 #24515]  INFO -- net.ssh.transport.server_version[51c7f8c]: negotiating protocol version
DEBUG ssh: == Net-SSH connection debug-level log END ==

Here trying with command line :

$ ssh -vvv -p 2222 -i /home/alx/.vagrant.d/insecure_private_key vagrant@localhost 
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to localhost [::1] port 2222.
debug1: connect to address ::1 port 2222: Connection refused
debug1: Connecting to localhost [127.0.0.1] port 2222.
debug1: Connection established.
debug3: Incorrect RSA1 identifier
debug3: Could not load "/home/alx/.vagrant.d/insecure_private_key" as a RSA1 public key
debug1: identity file /home/alx/.vagrant.d/insecure_private_key type -1
debug1: identity file /home/alx/.vagrant.d/insecure_private_key-cert type -1

Then if hangs...

Reply to this email directly or view it on GitHub:
https://github.com/roots/bedrock-ansible/issues/46#issuecomment-71288796

[alx]

Yes, it appears on the first time I'm setting up the vm with vagrant up command.

I've tried a few vagrant destroy/up with info from comments on this thread, but still get this same error.

[phpanos]

For me the files existed in /etc/ssh but were empty (Check /var/log/auth.log for the errors). So I removed all ssh_host* files and ran:
vagrant halt
vagrant destroy
vagrant up --provision

And that solved it for me.

[mmikeww]

I was having this same problem.

My issue was, I was trying a VM inside of a VM. I am on a Windows laptop. I installed Ubuntu guest into a VirtualBox VM on the Windows host. Then, inside that Ubuntu, I attempted to install trellis/vagrant/anothervirtualbox. And I ran into this SSH error.

This link recommended I turn on the vb.gui setting to debug, which showed me that it wasn't really an SSH problem, but some virtualization error:
https://discourse.roots.io/t/timed-out-while-waiting-for-the-machine-to-boot/5943/

Some more googling brought me to this link:
http://stackoverflow.com/questions/24620599/error-vt-x-not-available-for-vagrant-machine-inside-virtualbox

That link explained that the problem was the nested VM attempt. Apparently VirtualBox doesn't support nested 64-bit VMs. Installing VMWare Player on my Windows host, allowed me to nest the VMs successfully, and get past that "SSH" error.

[JJ]

I just had the same problem. It stopped after a while with the message:

    default: SSH auth method: private key
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.

However, checked VB and the machine seemed to be running, although it was not responding to ssh. I tried vagrant up again and it up and started without an (apparent) problem, although it required to enter the sudo password.

[ghost]

I checked folder .vagrant\machines\default\virtualbox, I saw don't have file private_key. I added that and ran vagrant reload it ok.

[lehien]

I solved this problem with:
vagrant halt
vagrant up --provision
But it is really annoyed because in some day, this problem comes back and I have to use the above way.

[kmurudi]

Fixed for me too after deleting/destroying previously created vms.