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

Bug #1569237 reported by domnulnopcea on 2016-04-12
374
This bug affects 77 people
Affects Status Importance Assigned to Milestone
Xenial Backports
Undecided
Unassigned
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 :)

Robert Skolnick (nvsdi) wrote :

i want to thank David Warkentin (ev0rtex). his new box worked out of the gate.
i consult 23 customers that use vagrant ubuntu14. i am upgrading them to ev0rtex/ubuntu16.
after a week of not getting the ubuntu box working i came to the conclusion that the team issuing the box were potty trained at gun point making them anal retentive. only reason for them not fixing this issue. 16 of my customers donate to them every year. i have asked to stop.
its been over a year and they do not understand that if you issue a vagrant box it has to meet the base requirements.it is what makes vagrant usable.not doing so is again being ANAL RETENTIVE!

Joel Handwell (joelhandwell) wrote :

https://atlas.hashicorp.com/joelhandwell/boxes/ubuntu_xenial64_vbguest this box is created based on ubuntu/xenial64 adds sudo user vagrant. Used following Vagrantfile:

https://github.com/joelhandwell/ubuntu_vagrant_boxes/blob/master/u16/Vagrantfile

$script = <<SCRIPT
echo "create user vagrant"
adduser --disabled-password --gecos "" vagrant
echo 'vagrant:vagrant' | chpasswd
ls -al /home/
echo "add sudo privilege to user vagrant"
cp /etc/sudoers.d/90-cloud-init-users /etc/sudoers.d/admin
chmod +w /etc/sudoers.d/admin
ls -al /etc/sudoers.d/
sed -i 's/ubuntu/vagrant/g' /etc/sudoers.d/admin
cat /etc/sudoers.d/admin
echo "enable ssh access for user vagrant"
mkdir /home/vagrant/.ssh
chown vagrant:vagrant /home/vagrant/.ssh
cat /home/ubuntu/.ssh/authorized_keys > /home/vagrant/.ssh/authorized_keys
chown vagrant:vagrant /home/vagrant/.ssh/authorized_keys
su - vagrant -c "cat /home/vagrant/.ssh/authorized_keys"
chmod 600 /home/vagrant/.ssh/authorized_keys
ls -al /home/vagrant/.ssh
chmod 700 /home/vagrant/.ssh
ls -al /home/vagrant
sudo apt update -y
sudo apt full-upgrade -y
sudo apt-get autoremove -y
sudo systemctl disable apt-daily.service
sudo systemctl disable apt-daily.timer
SCRIPT

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/xenial64"
  config.vm.synced_folder ".", "/vagrant", disabled: true
  config.vm.provider "virtualbox" do |v|
    v.memory = 4096
    v.cpus = 4
  end
  config.ssh.username = "ubuntu"
  config.vm.provision "shell", inline: $script
end

Max (mbigras22) wrote :

For folks who scrolled to the bottom. I've switched to [bento/ubuntu-16.04](https://atlas.hashicorp.com/bento/boxes/ubuntu-16.04) and it works flawlessly.

Koustubh Sinkar (ksinkar) wrote :

This is ridiculous. I don't understand why Canonical has to go out of their way in making other people lives miserable. It seems they have forgotten the very meaning of the word *ubuntu*.

Changed in vagrant:
status: Invalid → Opinion
Changed in cloud-images:
status: New → Confirmed
Changed in vagrant:
status: Opinion → Confirmed

Is there a reason why this has not been addressed? I've wasted hours on this! As someone mentioned earlier, this non-response is the very anti-thesis of the word "ubuntu". People have even provided fixes and scripts to fix this and still no fixes or even a response. This is bizarre and sad.

Romel Sandoval (romel-n) wrote :

Not using this box because of this bug.

windowsguy (something-f) wrote :

Really annoying and quite ridiculous (1+ year!).

Switched to https://atlas.hashicorp.com/bento/boxes/ubuntu-16.04 for "deb" distro needs. Works great (vagrant/vagrant, only 31 new packages on apt-get update) and downloads much faster (maybe because more users, better caching). "vagrant box add bento/ubuntu-16.04"

Andrew Lenards (lenards) wrote :

+1 to this being annoying.

I'd also like to point out to any community folks following along, this is harmful to my opinion of Canonical, as a whole.

I have successfully done a `vagrant up` on the bento/ubuntu-16.04 mentioned.

/shrug I guess I should also be considering just going back to Debian.

Thinking further on this, the Ubuntu/xenial64 ships with an apparently empty cloudinit disk, would it not be possible to populate this with a cloud-init directive to inject the "insecure" key into the Ubuntu user account?

The docs here http://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups imply it should be as easy as:

#cloud-init
users:
 - name: ubuntu
   gecos: ubuntu
   sudo: ALL=(ALL) NOPASSWD:ALL
   groups: users, admin
   ssh-import-id: None
   ssh-authorized-keys:
    - <insecure key>

But, I'm sure things are never that easy!

To re-enforce someone's earlier comment, the delay to boot this image might actually be the problem. Perhaps the fix here is, instead of my previous line, to simply put a much longer config.vm.boot_timeout in the included vagrantfile with the box - 1200 was not sufficient, but moving to 65535 was clearly much more than required.

Sean Kugele (skugele) wrote :

Confirmed that this is still an issue.

Would someone from Canonical please comment on the status of this issue and whether there is any plan to address it?

We are approaching 1.25 years with this issue and 60+ comments from affected users, but no comment on direction from maintainers.

vude (vude) wrote :

Throwing another comment into the void. It would be nice to have some official word on why this issue hasn't even been addressed going on 2 years.

Changed in xenial-backports:
assignee: nobody → Kalu Victor Ude (vude)
assignee: Kalu Victor Ude (vude) → nobody

I'm in awe. I've wasted hours of my life now fighting with this box, all because nobody at Canonical could be bothered to (1) set it up according to the parameters that all public boxes are supposed to follow or (2) fix a trivial misconfiguration issue after dozens of people spent a year-plus pointing it out and documenting how to fix it.

If Canonical isn't willing to fix problems this simple, you should at least take this box (and any others that are similarly brain-damaged) down from Vagrant Cloud so future users don't step into the same lava pit. I went with this box precisely because I trusted Canonical over anyone else to provide a reliable, safe Ubuntu image; I have to assume lots of other people did (and will continue to do!) as well.

Continuing to put forward a box with known, fatal flaws as Canonical's official, "blessed" image actively hurts people who trust your company, which is a bad look. Fix it if you can, but if you can't, at least take it down.

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.