Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot ssh into generic/ubuntu1604 (virtualbox, 1.8.24) #4

Closed
berney opened this issue Aug 21, 2018 · 2 comments
Closed

Cannot ssh into generic/ubuntu1604 (virtualbox, 1.8.24) #4

berney opened this issue Aug 21, 2018 · 2 comments

Comments

@berney
Copy link

berney commented Aug 21, 2018

I cannot ssh into generic/ubuntu1604, provider virtualbox, version 1.8.24.

If I log into the console sshd is running and listening on port 22, however there is an error in the logs

error: Could not load host key: /etc/ssh/ssh_host_rsa_key
error: Could not load host key: /etc/ssh/ssh_host_dsa_key
error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
error: Could not load host key: /etc/ssh/ssh_host_ed25519_key
> vagrant up --provider virtualbox
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'generic/ubuntu1604'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'generic/ubuntu1604' is up to date...
==> default: Setting the name of the VM: generic_ubuntu1604_default_1534863324235_72684
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (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: 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...
The guest machine entered an invalid state while waiting for it
to boot. Valid states are 'starting, running'. The machine is in the
'unknown' state. Please verify everything is configured
properly and try again.

If the provider you're using has a GUI that comes with it,
it is often helpful to open that and watch the machine, since the
GUI often has more helpful error messages than Vagrant can retrieve.
For example, if you're using VirtualBox, run `vagrant up` while the
VirtualBox GUI is open.

The primary issue for this error is that the provider you're using
is not properly configured. This is very rarely a Vagrant issue.
> ssh vagrant@127.0.0.1 -p 2460
Connection closed by 127.0.0.1 port 2460
@ladar
Copy link
Member

ladar commented Aug 21, 2018

I'm currently rebuilding all of the 1.8.24 boxes from scratch. Unfortunately it will take a few days to finish the full build, and then complete a test run with the robots I have, but should the issue resurface, please (re)open an issue.

@ladar ladar closed this as completed Aug 21, 2018
@ladar ladar reopened this Aug 21, 2018
@ladar
Copy link
Member

ladar commented Aug 21, 2018

I'm sorry. I thought this issue was related to something else. The newest builds delete the SSH host keys before shutting down, so they can generate unique keys when cloned via vagrant. One of a series of security features I'm planning to add over time.

Unfortunately, unlike Red Hat, openSUSE, etc, Ubuntu (and possibly others, still checking), don't automatically regenerate their keys during boot, if they are missing. I've figured out a fix, and will be uploading new boxes, as 1.8.26 when my robots are available (aka soon). In the meantime, the 1.8.14 should work fine.

@ladar ladar closed this as completed in 414f553 Aug 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants