vagrant up asks for docker password

[mitchellh]

vagrant up asks for docker password

[xacaxulu]

+1 v 1.7.4

Somehow, password is "tcuser" and I found that on StackOverflow.

[vmpj]

Running vagrant 1.8.1 on OSX and getting this message when doing vagrant up

➜  vagrant up
    Bringing machine 'default' up with 'docker' provider...
    ==> default: Docker host is required. One will be created if necessary...
        default: Docker host VM is already ready.
    ==> default: Syncing folders to the host VM...
        default: The machine you're rsyncing folders to is configured to use
        default: password-based authentication. Vagrant can't script rsync to automatically
        default: enter this password, so you'll likely be prompted for a password
        default: shortly.
        default:
        default: If you don't want to have to do this, please enable automatic
        default: key insertion using `config.ssh.insert_key`.
        default: Rsyncing folder: /path/to/project/ => /var/lib/docker/docker_1459824852_72957
    [email protected]'s password:

tcuser is the password rsync is looking for but I want to avoid having to enter a password at all.
I'm using the default boot2docker box provided by vagrant which I assume is configured to use password-based authentication as stated by the message.

So my question is, why does the default boot2docker box, provide by vagrant, use password-based authentication?
Can we change it?
Or is there another boot2docker box I can use that will not require me to enter a password?

Thanks all!

[dduportal]

Hello @ramsrib ! Since i'm not related to hashicorp, I'm not an "issue manager" there :)

Outside this, you have to know that boot2docker will be dropped at any moment by docker:

• The rely on Alpine Linux to build "moby", the underlying light OS for Docker4mac and Docker4Windows natives
• Tiny Core has left a lot of support, this is the reason of the move to alpine

So using boot2docker is not a long term solution, especially given the overhead of moving to "ram-based" os, with immutable state, when you are using vagrant, a tool mainly dedicated to provisionning pattern :) Given the recent ubuntu and debian os upgrade, the size of the baseboxes have lowered a lot in 2 year, and moving to a debian basebox for your vagrant docker basebox may help a lot there , gaining time for you not hitting this kind of limitation :)

=> If you're relying on vagrant to start your container stack, I strongly recommend you to use docker-compose:

• Vagrant will be an "Docker Engine provider", that will just run a shell provision command : docker-compose up.
• Docker-COmpose will handle your container lifecycle in an easier way: always in sync with Docker :)

Good luck !

[karlingen]

I managed to solve this by adding the username and password for the ssh user to my Vagrantfile:

config.ssh.username = 'docker'
config.ssh.password = 'tcuser'

Quick update: I managed to log in using a couple of methods after a bit of trial and error:

1: Update VagrantFile with these settings:

    config.ssh.insert_key = true
    config.ssh.username = 'docker'
    config.ssh.password = 'tcuser'
    config.ssh.guest_port = 2222
    config.ssh.port = 22
    config.ssh.host = '127.0.0.1'

I suspect setting the ssh host is what made the difference as I was getting a 'connection refused' message after I typed the 'tcuser' password.

Interestingly using this method, I have to type the password twice, so I guess this is being tunnelled in some way - here's the output I get after using 'vagrant ssh'

vagrant ssh
==> default: SSH will be proxied through the Docker virtual machine since we're
==> default: not running Docker natively. This is just a notice, and not an error.
==> default: The machine you're attempting to SSH into is configured to use
==> default: password-based authentication. Vagrant can't script entering the
==> default: password for you. If you're prompted for a password, please enter
==> default: the same password you have configured in the Vagrantfile.
[email protected]'s password: tcuser
Warning: Permanently added '127.0.0.1' (ECDSA) to the list of known hosts.
[email protected]'s password: tcuser
                        ##         .
                  ## ## ##        ==
               ## ## ## ## ##    ===
           /"""""""""""""""""\___/ ===
      ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ /  ===- ~~~
           \______ o           __/
             \    \         __/
              \____\_______/
 _                 _   ____     _            _
| |__   ___   ___ | |_|___ \ __| | ___   ___| | _____ _ __
| '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |_) | (_) | (_) | |_ / __/ (_| | (_) | (__|   <  __/ |
|_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
Boot2Docker version 1.7.0, build master : 7960f90 - Thu Jun 18 18:31:45 UTC 2015
Docker version 1.7.0, build 0baf609

2: The other method I used which is less onerous is just to ssh directly:

ssh docker@localhost -p 2222

and type the 'tcuser' password.

I'm thinking it would make much more sense if the boot2docker image required no password at all or alternatively could be set up to use a certificate. But this will at least get me going, so good enough for me.

Another method:

Find the VM name using:

vagrant global-status | grep docker-host

which gives the VM machine:

20c4ac5  default virtualbox running /Users/simon/.vagrant.d/data/docker-host

and then use (substituting whatever the VM name is):

vagrant ssh 20c4ac5
==> default: The machine you're attempting to SSH into is configured to use
==> default: password-based authentication. Vagrant can't script entering the
==> default: password for you. If you're prompted for a password, please enter
==> default: the same password you have configured in the Vagrantfile.
[email protected]'s password: tcuser
                        ##         .
                  ## ## ##        ==
               ## ## ## ## ##    ===
           /"""""""""""""""""\___/ ===
      ~~~ {~~ ~~~~ ~~~ ~~~~ ~~~ ~ /  ===- ~~~
           \______ o           __/
             \    \         __/
              \____\_______/
 _                 _   ____     _            _
| |__   ___   ___ | |_|___ \ __| | ___   ___| | _____ _ __
| '_ \ / _ \ / _ \| __| __) / _` |/ _ \ / __| |/ / _ \ '__|
| |_) | (_) | (_) | |_ / __/ (_| | (_) | (__|   <  __/ |
|_.__/ \___/ \___/ \__|_____\__,_|\___/ \___|_|\_\___|_|
Boot2Docker version 1.7.0, build master : 7960f90 - Thu Jun 18 18:31:45 UTC 2015
Docker version 1.7.0, build 0baf609
docker@boot2docker:~$ exit
Connection to 127.0.0.1 closed.

This seems to cut out having to type the password twice.

[dduportal]

See that merged-PR : dduportal#5 (comment) .
@Freyskeyd has found that adding config.ssh.insert_key = false will make vagrant 1.7.x not messing up with boot2docker.

=> Add it to the vagrantfile.tpl, it's vagrant >= 1.6.x backward compatible :)

[Freyskeyd]

Just put into your VagrantFile:
config.ssh.insert_key = false

it should work as expected next time. (Maybe you need to destroy vm to make it working)

[karlingen]

Yup. Adding config.ssh.insert_key = false to my Vagrantfile solved the issue. Thanks guys!
@Freyskeyd @dduportal

[karlingen]

It seems like it was only a temporary fix.
I'm still getting the same output:

$ vagrant up
Bringing machine 'db' up with 'docker' provider...
==> db: Docker host is required. One will be created if necessary...
    db: Vagrant will now create or start a local VM to act as the Docker
    db: host. You'll see the output of the `vagrant up` for this VM below.
    db:
    db: Checking if box 'mitchellh/boot2docker' is up to date...
    db: Clearing any previously set forwarded ports...
    db: Clearing any previously set network interfaces...
    db: Preparing network interfaces based on configuration...
    db: Adapter 1: nat
    db: Forwarding ports...
    db: 2375 => 2375 (adapter 1)
    db: 5432 => 5432 (adapter 1)
    db: 22 => 2222 (adapter 1)
    db: Running 'pre-boot' VM customizations...
    db: Booting VM...
    db: Waiting for machine to boot. This may take a few minutes...
    db: SSH address: 127.0.0.1:2222
    db: SSH username: docker
    db: SSH auth method: private key
    redis: Warning: Connection timeout. Retrying...
Text will be echoed in the clear. Please install the HighLine or Termios libraries to suppress echoed text.
[email protected]'s password:

[karlingen]

hum.. that was wierd. I just had to wait until it timed out (without providing any password or sending any keystrokes) and then it continued the process.

[dduportal]

@karlingen : don't forget to remove the line config.ssh.password

[karlingen]

@dduportal I don't have that line anywhere in my file.

Vagrantfile:

VAGRANTFILE_API_VERSION = "2"
ENV['VAGRANT_DEFAULT_PROVIDER'] ||= 'docker'

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.ssh.insert_key = false

  config.vm.define "db" do |app|
    app.vm.provider "docker" do |d|
      d.image = "postgres:9.4.1"
      d.name = "base_db"
      d.ports  = ['5432:5432']
      d.vagrant_vagrantfile = "Vagrantfile.host"
    end
  end
end

and my Vagrantfile.host:

Vagrant.configure("2") do |config|

  config.vm.box = "mitchellh/boot2docker"
  config.vm.provider "virtualbox" do |v|
    v.check_guest_additions = false
    v.functional_vboxsf     = false
    v.customize ['modifyvm', :id, '--memory', 1024]
    v.customize ['modifyvm', :id, '--acpi', 'on']
    v.customize ['modifyvm', :id, '--cpus', 1]
    v.customize ['modifyvm', :id, '--cpuexecutioncap', '100']
    v.customize ['modifyvm', :id, '--natdnshostresolver1', 'on']
    v.customize ['modifyvm', :id, '--natdnsproxy1', 'on']
  end

  config.nfs.functional = false

  config.vm.network :forwarded_port, guest: 5432, host: 5432
end

[karlingen]

I managed to solve this by removing the two boot2docker key files located in ~/.ssh/

[davidthewatson]

I'm having this problem with Vagrant 1.7.2 and the following Vagrantfile:

VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
    config.vm.hostname = "my-django-dev"
    config.ssh.insert_key = false
    config.vm.provider "docker" do |d|
         d.image = "ubuntu"
    end
    config.vm.network "forwarded_port", guest: 80, host: 8080
    config.vm.network "forwarded_port", guest: 443, host: 8443
    config.vm.network "forwarded_port", guest: 5432, host: 5432
end

I still get the password prompt for [email protected] whether I have insert_key=false
or I have deleted the boot2docker keys in ~/.ssh/.

Is there any way around this other than the two aforementioned methods? Thanks!

[dduportal]

Hi @davidthewatson : can you provide us the vagrant debug log ?
Steps :

• Run from a clean VM (use vagrant destroy before if needed)
• activate vagrant debug trace : export VAGRANT_LOG=1 (or set VAGRANT_LOG=1 on Windows)
• In the same command line, run your vagrant up (and mayber vagrant reload).
• Copy paste the trace to a Gist and provide us the link here.

Thanks !

[bantonj]

I am having this issue. I've tried adding config.ssh.insert_key = false to the Vagrantfile, and deleting the boot2docker ssh keys. I've pasted the debug log from vagrant up in the gist below.

Vagrantfile:

# -*- mode: ruby -*-
# vi: set ft=ruby :

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.ssh.insert_key = false
  config.vm.define "elasticsearch" do |es|
    es.vm.provider "docker" do |container|
      container.image = "dockerfile/elasticsearch"
      container.ports = [ "9200:9200", "9300:9300" ]
      container.remains_running = true
    end
  end
end

https://gist.github.com/bantonj/4e6f5d4e89595bfd1683

I appreciate any help. Thanks.

[dduportal]

Hello @bantonj , it seems that you have a slightly different problem.

In your case, you want to rsync to the @mitchellh box (hashicorp/boot2docker in Atlas as stated by vagrant documentation on this page http://docs.vagrantup.com/v2/docker/basics.html).

As written here : https://github.com/mitchellh/boot2docker-vagrant-box/blob/master/vagrantfile.tpl#L4 (supposing this is the good repository mapped to the box), we see that SSH is configured in the box to use password connexion.

Your gist confirmed that at this line : https://gist.github.com/bantonj/4e6f5d4e89595bfd1683#file-gistfile1-txt-L846

So there is absolutely no ssh key at all (behaviour before was to use the vagrant insecure key - https://github.com/mitchellh/vagrant/tree/master/keys ).

In this case, vagrant-rsync cannot handle it and tells you that since it cannot store the password at its level.

I'm not sure how to correctly handle that :

• My fork of the box (https://atlas.hashicorp.com/dduportal/boxes/boot2docker | https://github.com/dduportal/boot2docker-vagrant-box) use the old behaviour, given the security level is low, maybe it will fit on your use case, but it's not really good at long term since it is not is the hashicorp behaviour in vagrant
• Since you use docker, why not going to docker-machine and/or move to a different paradigm : a data volume container that embed a samba/nfs server to acces your file from your host (inverting sycned folder sharing)
• Do some work on the boot2docker box to fully support the key insertion : my thought is that it was not working due to some specific configuration in boot2docker ssh server : maybe it's worth it change this and embrace the key regenration to have a full vagrant support.

[danielfree]

Hi @dduportal , I came across the same issue when I was using a fresh installed vagrant 1.7.4. Since the change of hashicorp/boot2docker every time vagrant asks for the 'docker' user's password when rsyncing. I tried to add config.ssh.username and config.ssh.password but it didn't seem to work. The related Vagrantfile is https://github.com/amplab/tachyon/blob/master/deploy/vagrant/Vagrantfile

My question is: since the project is used by many other users that may not have Mac environment, is it safe to define d.vagrant_vagrantfile = '../path/file' as stated in http://docs.vagrantup.com/v2/docker/basics.html in order to replace the default host vm box 'hashicorp/boot2docker'? Will this change force every user use the defined box even if the user is in Linux and has docker installed? Thanks a lot!

[LongLiveCHIEF]

I'm also getting this problem on vagrant 1.7.4 on a Mac 10.11

[galet]

+1

[robsonpeixoto]

+1

➜  vagrant version
Installed Version: 1.7.4
Latest Version: 1.7.4

You're running an up-to-date version of Vagrant!

➜  sw_vers
ProductName:    Mac OS X
ProductVersion: 10.11.2
BuildVersion:   15C50

[josephfrazier]

I'm I was also experiencing this. Here's a minimal testcase I'm using, with various fixes attempted individually:

• #79 (comment)
• config.ssh.insert_key = false
• config.ssh.username = 'docker'; config.ssh.password = 'tcuser'
• config.vm.synced_folder ".", "/vagrant", disabled: true

vagrant version
Installed Version: 1.8.0
Latest Version: 1.7.4

You're running an up-to-date version of Vagrant!

sw_vers
ProductName:    Mac OS X
ProductVersion: 10.9.5
BuildVersion:   13F1112

[wangwenchao]

https://docs.vagrantup.com/v2/vagrantfile/ssh_settings.html
config the ssh username and password and insert_key to be true could resolve your problem

It doesn't. I've tried various combinations. I'm surprised nobody's found a solution for this in a year. I guess most people have just given up using Vagrant, and are just using native boot2docker. Too much effort to figure out the issue and a workaround, I guess. Shame.

[josephfrazier]

Thanks, @huggyfee! Your method worked for me as well.

[jjb]

Having the same experience as @vmpj and I am wondering the same thing -- why is this not a straightforward problem to solve? I am a vagrant and docker newb, so maybe there's more to it than I realize. Let me know if I can provide more info or a minimal test case.

[skqr]

+1
Any sort of workaround would be greatly appreciated in while a patch comes along. Thanks!

[ramsrib]

I'm also facing the same error.

@dduportal The reported problem doesn't seem to be fixed. Can you guys reopen this issue?

[ramsrib]

Thanks @dduportal for the explanation. I wonder when vagrant gonna switch to Docker4mac from boot2docker. Anyway, You're right, i better use docker compose instead of depending on vagrant.

[wizonesolutions]

Docker for Mac is still slow for shared files, so it might be some time.