vagrant xenial box is not provided with vagrant/vagrant username and password

Bug #1569237 reported by domnulnopcea on 2016-04-12
298
This bug affects 62 people
Affects Status Importance Assigned to Milestone
cloud-images
Undecided
Unassigned
vagrant
Undecided
Unassigned

Bug Description

It is Vagrant convention that the default user is named "vagrant"[0], and a whole host of scripts assume this to be the default.

The xenial box is substantially less useful to Vagrant users with the "ubuntu" user as the default, and there is limited benefit to having the "ubuntu" user.

[0] Search for "user to SSH" in https://www.vagrantup.com/docs/boxes/base.html.

domnulnopcea (domnulnopcea) wrote :

issue still present in image 20160420.3

christophe (christophe-bornet) wrote :

still present in v20160502.0.0

christophe (christophe-bornet) wrote :

Actually the whole vagrant base box configuration is missing (https://www.vagrantup.com/docs/boxes/base.html)

domnulnopcea (domnulnopcea) wrote :

Is there any activity here from ubuntu guys? the xenial vagrant image right now is not usable...

Tang Jianyu (jianyu) wrote :

I'm also getting this issue on v20160509.0.0, system is working but annoying

Jack Peterson (jack-peterson) wrote :

Still impacting Ubuntu 16.04 adoption. Vagrant is a great way to test functionality out and not having Xenial work with vagrant out of the box is frustrating to say the least. Can we get this assigned / triaged?

This is still an issue.

VirtualBox - Version 5.0.20 r106931

$ vagrant --version
Vagrant 1.8.1

$ vagrant box list | grep xenial
ubuntu/xenial64 (virtualbox, 20160606.1.0)

Jack Peterson (jack-peterson) wrote :

I'm cross-referencing this to the bug https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1589721 that I just posted. The bug above appears to be the correct place to place a report based on the email referenced at http://www.kennybastani.com/2015/08/polyglot-persistence-spring-cloud-docker.html

Jack Peterson (jack-peterson) wrote :

Steps to reproduce this issue:

$ vagrant init ubuntu/xenial64
$ vagrant up

Console output:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/xenial64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/xenial64' is up to date...
==> default: Setting the name of the VM: ubuntu-xenial-16.04-cloudimg
==> 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: ubuntu
    default: SSH auth method: password
    default: Warning: Remote connection disconnect. Retrying...
^C==> default: Waiting for cleanup before exiting...
    default: Warning: Connection refused. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
Vagrant exited after cleanup due to external interrupt.

Dan Watkins (daniel-thewatkins) wrote :

So this is what I see when I boot up the latest xenial64 box:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/xenial64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/xenial64' is up to date...
==> default: Setting the name of the VM: ubuntu-xenial-16.04-cloudimg
==> 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: ubuntu
    default: SSH auth method: password
    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: Warning: Remote connection disconnect. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!

(I'm looking at what the trusty box does now)

And this is what I see with trusty:

Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'ubuntu/trusty64'...
==> default: Matching MAC address for NAT networking...
==> default: Checking if box 'ubuntu/trusty64' is up to date...
==> default: Setting the name of the VM: trusty_default_1465318955637_45016
==> default: Clearing any previously set forwarded ports...
==> default: Fixed port collision for 22 => 2222. Now on port 2200.
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2200 (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:2200
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Remote connection disconnect. Retrying...
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!

So this looks pretty much the same, except my xenial box took longer to come up. Is it possible people are just seeing a timeout?

Jack Peterson (jack-peterson) wrote :

I can get this to sign in after a period of time with the ubuntu user (so that part works); however, I think the real issue is that the username / password defaults are inconsistent with the documentation on Vagrant's documentation https://www.vagrantup.com/docs/boxes/base.html -- which then causes later provisioning issues / machine portability issues.

So this ticket should reflect the need for the ubuntu/xenial64 image to match how ubuntu/trusty64 was configured for vagrant's recommendations with a default user of vagrant and a default password of vagrant with password-less sudo.

A workaround for this would be to create the vagrant user as a pre-provisioning step (assuming additional provisioners like puppet are used that depend on the vagrant user) with sudo permissions; however, that's a bit of a hack to get things to play nicely. An example of where something wouldn't play nicely is when one has baked in vagrant user availability / defaults and file/folder permissions for their provisioning steps.

OK, I've updated the bug description; the login timeouts were a red herring, this is really just about changing the default username.

(We can, and have, instructed Vagrant to SSH in using the correct user, but this information is not generally used outside of `vagrant ssh`)

description: updated
Changed in vagrant:
status: New → Invalid
Keilo (keilo) wrote :

This is slowing down 16.04 adoption due to breaking changes from 14.04 such as the default username and generally missing a lot of other standard settings that vagrant expects to find in the base box.

Can confirm that this affects ubuntu/xenial64 20160610.0.0

Jack Peterson (jack-peterson) wrote :

I abandoned using the Ubuntu/* vagrant images in favor of kaorimatz/ubuntu-16.04-amd64 (https://github.com/kaorimatz/packer-templates). This is at least an open-source project so you could rebuild the images from scratch if you so desired ... and it's built using the vagrant way rather than the super obscure ubuntu imaging way -- which I found almost no documentation to reproduce a local environment to create the images. I'd suggest going that route since everything works well out of the box and it's well documented as well as well-contributed to (fairly reliable).

Socketz (socketz) wrote :

Temporary solution:
1. Modify the Vagrantfile before to execute 'vagrant up' command:

  config.vm.provision "shell", inline: <<-SHELL
     passwd -d -u ubuntu
     chage -d0 ubuntu
  SHELL

2. Execute 'vagrant up --provider virtualbox' # or without provider args
3. After VM is up, click on Virtualbox to show the VM GUI and change the password.
4. Login on ssh with user ubuntu correctly.

domnulnopcea (domnulnopcea) wrote :

is this bug going to be addressed?

meteor (604733992-qq) wrote :

@socketz It works. Thanks.
When can Ubuntu fix this bug?

meteor (604733992-qq) wrote :
Sam Bull (dreamsorcerer) wrote :

This is causing issues for our development setup as well.

As per the documentation:
  By default, Vagrant expects a "vagrant" user to SSH into the machine as.
https://www.vagrantup.com/docs/boxes/base.html#quot-vagrant-quot-user

Flavio Fernandes (ffernand) wrote :

This is still an issue when using vagrant in xenial host,
with vbox 20160826.0.0

$ VBoxManage --version
5.0.24_Ubuntur108355

$ vagrant --version
Vagrant 1.8.5

$ vagrant box list | grep xenial
ubuntu/xenial64 (virtualbox, 20160826.0.0)

$ grep box Vagrantfile
    ubuntu.vm.box = "ubuntu/xenial64"

$ vagrant up
...
==> ubuntu: chown: invalid user: ‘vagrant:vagrant’
...

$ vagrant ssh
 INFO ssh: Invoking SSH: ssh ["ubuntu@127.0.0.1", "-p", "2222", "-o", "Compression=yes", "-o", "DSAAuthentication=yes", "-o", "LogLevel=FATAL", "-o", "StrictHostKeyChecking=no", "-o", "UserKnownHostsFile=/dev/null", "-o", "IdentitiesOnly=yes"]
ubuntu@127.0.0.1's password:

David Reagan (jerrac) wrote :

I can ssh into the box using the private key, or vagrant ssh. But if I want to just ssh in normally, I have to use a password. And I have no idea what the password for "ubuntu" would be. It would be much better to use the normal vagrant/vagrant user.

VBoxManage --version
5.1.0r108711

vagrant --version
Vagrant 1.8.4

xenial.vm.box = "ubuntu/xenial64"
xenial.vm.box_url = "https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-vagrant.box"

hey David a temp fix is to set the username and password for vagrant like so:
```ruby
Vagrant.configure(2) do |config|

  config.vm.define "master" do |master|
    config.ssh.username = "ubuntu"
    config.ssh.password = ""
    master.vm.box = "ubuntu/xenial64"
    master.vm.hostname = "master"
    master.vm.network :private_network, ip: "172.0.0.10"
  end

end
```
please note I've defined those attributes to the box if you want them to apply to all nodes ie your using all the same box you should place all three username password and box out side the define "master" block.

domnulnopcea (domnulnopcea) wrote :

hello,

the temp fix is not working. It still hangs asking for password.

Kristian Lewis Jones (klj613) wrote :

hello,

this affects me. all my scripts assumes the user is vagrant with the default ssh key. back to 14.04.

Ruijing (ruijing-guo) wrote :

who can help to triage this issue?

Ruijing (ruijing-guo) wrote :

where is source code to build vagrant box? we may help to fix the issue

denix (denics) wrote :

Ok, I confirm the problem is still present for version: 20161014.0.0

Concerning workarounds you can set:

# SSH options.
    config.ssh.insert_key = true
    config.ssh.forward_agent = true

which will copy your public ssh key in the "ubuntu" account. You'll be then able to login using
vagrant ssh

If you want you can also set a password during your provision phase (I've tested with a shell provision), or make sure that your user is listed in the sudoers users. @ruijing-guo Having the source code for the box would indeed help fixing the issue!

Denis

Brian (egee-irl) wrote :

This is a pretty serious but and I am not sure why it isn't being triaged by the Ubuntu team. The fix is trivial on Canonical's end.

Bogdan Ghervan (bogdanghervan) wrote :

I get it that vagrant / vagrant should be the default, but what is the default password for the "ubuntu" account? I already tried "ubuntu", "vagrant" and a blank password, clearly I'm missing something.

auxbuss (launchpad-auxbuss) wrote :

Astonished that no-one has looked into this. I'm abandoning the Ubuntu boxes, because there is no indication that they have an interest in maintaining them.

Florian Heyer (heyho-flanto) wrote :

This problem still exists in
ubuntu/xenial64 (virtualbox, 20161104.0.0)
Please fix!

David Warkentin (ev0rtex) wrote :

This is killing me - I just installed the latest 20161104.0.0 and experienced this. I was stuck on this for hours trying to find a workaround before giving up (and just now finding this issue). All of my scripts, SaltStack configs, etc. rely on the user being 'vagrant' and I can't just simply adapt to this change - I could spend days on this. Canonical...please pay attention and help us out!

David Warkentin (ev0rtex) wrote :

FYI, to all those who want a working base box I gave up and just repackaged a corrected version of ubuntu/xenial64 last night. Mine is on atlas as "v0rtex/xenial64" and so far I only did a version for the virtualbox provider since I do not have vmware at the moment.

I updated guest additions and package versions and then changed the username from 'ubuntu' to 'vagrant' along with all the dependent sudo, group and permission fixes. This is working great for me so far.

ubuntu/xenial64/32 boxes have been incorrectly packaged since conception and Ubuntu team hasn't even attempted to fix many known issues. I can only guess, Ubuntu is not interested at all in providing usable vagrant boxes.

Andrew Robbins (agdrew) wrote :

ubuntu/xenial64 is useless, when is this going to be fixed?

Joel Handwell (joelhandwell) wrote :

Ubuntu 14 and 12 vagrant boxes are using vagrant/vagrant username/password and keep updating. So I assume ubuntu team acknowledges that there is demand for vagrant box. There should be more direct communication channel outside of launchpad to reach their decision making process or priority setter person.

Visnusaran Murugan (ckmvishnu) wrote :

Adding the below mentioned config to Vagrantfile, i'm able to "vagrant ssh" in to 16.04 machine.

config.ssh.username = "ubuntu"

I've created a golang devbox based on xenial and using it without issues.

leed (leed) wrote :

Seriously, this needs fixing. I don't want to have to instruct all co-workers that they should be using the "ubuntu" user instead of the "vagrant" user. Besides the fact, that the "ubuntu" user has issues with the password and uses a different root path and also can't provision correctly without using sudo.

Please fix this back to the previous vagrant:vagrant user. We have enough other problems and new things to learn.

ugmoe2000 (ericpulvino) wrote :

Please address this, the image is almost useless if users cannot easily log in.

gitarr (gitarr) wrote :

Why is this cloud image on atlas.hashicorp.com as the official Ubuntu vagrant box?

(https://atlas.hashicorp.com/ubuntu/boxes/xenial64)

This box isn't configured right and just not working for vagrant. This is your current LTS release? I'd be ashamed at this point.

Shashank K (skmurthy85) wrote :

Is there any update on this. The issue is still present

christophe (christophe-bornet) wrote :

Don't use the ubuntu box : it's broken in many ways and I don't think the ubuntu team intends to make a true vagrant box. So use https://atlas.hashicorp.com/bento/boxes/ubuntu-16.04 instead.

prometee (prometee) wrote :

According to the Vagrantfile in ~/.vagrant.d/ubuntu-VAGRANTSLASH-xenial64/20161221.0.0/virtualbox/Vagrantfile
the password is : bce13c362bdf6d1518510c23

I solved this problem by changing the ubuntu password via:

    config.vm.provision "shell", inline: <<-SHELL
      echo "ubuntu:ubuntu" | sudo chpasswd
    SHELL

Robie Basak (racb) wrote :

I appreciate this bug report having been filed. I also don't think this is simply a case of some code that needs fixing. We also need to have a higher level decision as to whether it is appropriate to make the change first, and to my knowledge no such decision has been made yet.

See https://irclogs.ubuntu.com/2016/07/06/%23ubuntu-devel.html#t12:30 for a previous conversation on this. Also note that participants in this bug only represent one side of the conversation.

Jiri Tyr (jtyr) wrote :

I's completely useless to produce Vagrant boxes if users can not use them. There should be the standard vagrant:vagrant and root:vagrant credentials on all Vagrant boxes. Please fix it!

dizeee (dizeee) wrote :

In our team we actually managed to make it work, but we had to tinker a bit with our provisioners. Now we can't just switch to another box instantly, which is not a major issue but pretty stinky one though.

Chris Olin (chris.olin) wrote :

I wanted to chime in as this bug caused me to waste the better part of a day due to the issues it initially caused. On top of that, I have to now go and provision a new box based on the correctly configured images that others have put together (mentioned above) due to Canonical's lack of attention here.

This bug is causing numerous issues and headaches that are unnecessary. As many others have pointed out, the fix is trivial. Even more frustrating is that there is a widely accepted convention for Vagrant images that was completely ignored in the official Xenial image. This isn't up for discussion or debate, nor does it need a "higher level decision" to fix. This bug should have been triaged and fixed months ago. Period. There is a needless amount of bureaucratic dysfunction and pedantry taking place here is both appalling and goddamn embarrassing.

Stop this madness and fix it! No more bullshit, no more excuses. If you can't do that, stop releasing Vagrant images. Let others who can adhere to such elementary conventions release them instead.

Just noticed that the insecure key was not set and snooped around and saw the username was not correctly created. I am attempting to updated a couple sites both Ubuntu and latter to PHP7. For now I am not running into many issues that are show stoppers but seems like this could really hose some scripts down the road and also has the additional impact that once it is switched that is more rework.

https://www.vagrantup.com/docs/boxes/base.html#default-user-settings

If there is any help that can be provided more then willing to pitch in.

Lorin Hochstein (lorinh) wrote :

@racb The linked IRC discussion appears to be about the tradeoffs of pre-installing config management software (e.g, chef, puppet). This ticket is about having a "vagrant" account in the Vagrant box. Is anyone arguing against using the standard Vagrant conventions for a vagrant account in the xenial box?

Nitin Bodke (nitin.bodke) wrote :

As given by Visnusaran Murugan (ckmvishnu),
Adding 'config.ssh.username = "ubuntu"' in vagrant file helped me to login.

Below is my vagrant file:
<snip>
# This guide is optimized for Vagrant 1.7 and above.
# Although versions 1.6.x should behave very similarly, it is recommended
# to upgrade instead of disabling the requirement below.
Vagrant.require_version ">= 1.7.0"

Vagrant.configure(2) do |config|

  config.vm.box = "ubuntu/xenial64"

  # Disable the new default behavior introduced in Vagrant 1.7, to
  # ensure that all Vagrant machines will use the same SSH key pair.
  # See https://github.com/mitchellh/vagrant/issues/5005
  config.ssh.insert_key = false
  config.ssh.username = "ubuntu"

  config.vm.provision "ansible" do |ansible|
    ansible.verbose = "v"
    ansible.playbook = "playbook.yml"
  end
end
</snip>

NOTE: I am using ansible provisioner. But this has nothing to do with issue.

Hello,

It's been nearly a year since this issue has been filed.

There are some minimum requirements for Vagrant to function (https://www.vagrantup.com/docs/boxes/base.html).
If you are to provide an official ubuntu box, just meet those requirements.
If you are to meet some others requirements (Ubuntu users expect to share the same experience, aka having a ubuntu user) then do it if you want, but at least meet the requirements of the technology you provide an official image.

Excerpt from https://www.vagrantup.com/docs/boxes/base.html: Perhaps Chef, Puppet, etc. but not strictly required.
If you do not want to ship them, then don't, but at least state it.

In fact, state anything on that one-year-old ticket

vdloo (rickvandeloo) wrote :

> If you do not want to ship them, then don't, but at least state it.

Agreed. Working with a box without a vagrant user isn't that hard but since this is the box that I guess most people will end up using first when they want to quickly start a Xenial Vagrant it's a shame that this does not conform to the expected standard. I'm sure many people have wasted a lot of time on this.

Matthew Hart (mattou07) wrote :

I managed to get it working by changing my Vagrant version to 1.9.2 and VirtualBox to 5.1.12
Then I added a vagrant plugin for guest additions like this:

vagrant plugin install vagrant-vbguest

And it creates the VM and runs my provisions. I am using Windows 10.

I hope that helps some of you guys :)

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.