SSH public key isn't created in vagrant cloud images

[Matthias Baur]

Bug: SSH public key isn't created in vagrant cloud images

Reproduction:
- Download: http://cloud-images.ubuntu.com/vagrant/raring/current/raring-server-cloudimg-amd64-vagrant-disk1.box
- Start with vagrant or manual with VirtualBox
- Look into /etc/ssh

Environment:
- Ubuntu 13.04
- vagrant 1.0.3-1ubuntu3
- VirtualBox 4.2.10-dfsg-0ubuntu2.1

Also, please have a look at this thread: http://askubuntu.com/questions/324574/cannot-ssh-into-new-vagrant-install-of-13-04/

Thanks in advance! :)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Moshe Katz (kohenkatz)]

This appears to be a problem in certain daily builds only. I don't have the exact dates of when it started and stopped working, but I was able to reproduce several times in June, July, and August. After that, I was unable to reproduce using a build made on August 20th, 2013, but then I was able to reproduce it (with a 32-bit build) after that.

[allpoints (ubug-allpointsconsulting)]

As a point of information, the virtual instance works fine on the second boot.

i.e. if you" vagrant up: vagrant halt; vagrant up" everything works as expected with the exception that the post provisioning/configuration process will have failed.

System configuration:
  Ubuntu image: http://cloud-images.ubuntu.com/vagrant/raring/20130917/raring-server-cloudimg-amd64-vagrant-disk1.box
  Host Distribution/Release: Linux Mint 14/Nadia which is based on Ubuntu Quantal
  Vagrant version: 1.3.1
  VirtualBox package: Oracle maintained, version 4.2.18-88780~Ubuntu~precise

As an additional check, I attempted to SSH in manually after the VM had booted. The debug output is attached.

[Daniel Nephin (dnephin)]

I've hit this bug as well.

I've tried it with the following images:

  http://cloud-images.ubuntu.com/vagrant/raring/20130917/raring-server-cloudimg-amd64-vagrant-disk1.box
  http://cloud-images.ubuntu.com/vagrant/raring/20130921/raring-server-cloudimg-amd64-vagrant-disk1.box
  http://cloud-images.ubuntu.com/vagrant/raring/20130924/raring-server-cloudimg-amd64-vagrant-disk1.box

[Brian Lalor (blalor)]

Having this problem as well.

[Brian Lalor (blalor)]

Errors in auth.log show:

Sep 26 19:43:51 vagrant-ubuntu-raring-64 sshd[1442]: error: Could not load host key: /etc/ssh/ssh_host_rsa_key
Sep 26 19:43:51 vagrant-ubuntu-raring-64 sshd[1442]: error: Could not load host key: /etc/ssh/ssh_host_dsa_key
Sep 26 19:43:51 vagrant-ubuntu-raring-64 sshd[1442]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
Sep 26 19:43:53 vagrant-ubuntu-raring-64 sshd[1442]: fatal: No supported key exchange algorithms [preauth]

Problem temporarily worked-around by doing this:

sudo ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key -N '' -t ecdsa
sudo ssh-keygen -f /etc/ssh/ssh_host_dsa_key -N '' -t dsa
sudo ssh-keygen -f /etc/ssh/ssh_host_rsa_key -N '' -t rsa

[Marcelo Alvim (malvim)]

There's a new "batch" of machines (from Sep 28, 2013), and I was able to import them on VirtualBox and verify that they have the previously missing files. I could then ssh into my imported machine without problems.

When I do "vagrant up", though, the files are not there, which is very weird, but I'll look into that a little better.

[Ben Howard (darkmuggle-deactivatedaccount)]

ApportVersion: 2.9.2-0ubuntu8.3
Architecture: amd64
DistroRelease: Ubuntu 13.04
MarkForUpload: True
Package: cloud-init 0.7.2-0ubuntu0.13.04.1
PackageArchitecture: all
ProcVersionSignature: Ubuntu 3.8.0-30.44-generic 3.8.13.6
Tags: raring uec-images
Uname: Linux 3.8.0-30-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

[Ben Howard (darkmuggle-deactivatedaccount)]

apport information

[Ben Howard (darkmuggle-deactivatedaccount)]

apport information

[Ben Howard (darkmuggle-deactivatedaccount)]

From the logs, the local datasource for cloud-init is not claiming the datasource on the first run. If you run cloud-init again, it claims the data source again.

2013-09-30 14:36:00,208 - __init__.py[DEBUG]: Seeing if we can get any data from <class 'cloudinit.sources.DataSourceNoCloud.DataSourceNoCloud'>
2013-09-30 14:36:00,208 - util.py[DEBUG]: Reading from /proc/cmdline (quiet=False)
2013-09-30 14:36:00,209 - util.py[DEBUG]: Read 119 bytes from /proc/cmdline
2013-09-30 14:36:00,209 - util.py[DEBUG]: Reading from /var/lib/cloud/seed/nocloud/meta-data (quiet=False)
2013-09-30 14:36:00,212 - util.py[DEBUG]: Running command ['blkid', '-odevice', '/dev/sr0'] with allowed return codes [0, 2] (shell=False, capture=True)
2013-09-30 14:36:00,224 - util.py[DEBUG]: Running command ['blkid', '-tTYPE=vfat', '-odevice'] with allowed return codes [0, 2] (shell=False, capture=True)
2013-09-30 14:36:00,252 - util.py[DEBUG]: Running command ['blkid', '-tTYPE=iso9660', '-odevice'] with allowed return codes [0, 2] (shell=False, capture=True)
2013-09-30 14:36:00,268 - util.py[DEBUG]: Running command ['blkid', '-tLABEL=cidata', '-odevice'] with allowed return codes [0, 2] (shell=False, capture=True)
2013-09-30 14:36:00,285 - __init__.py[DEBUG]: Seeing if we can get any data from <class 'cloudinit.sources.DataSourceConfigDrive.DataSourceConfigDrive'>
2013-09-30 14:36:00,285 - util.py[DEBUG]: Running command ['blkid', '-odevice', '/dev/sr0'] with allowed return codes [0, 2] (shell=False, capture=True)
2013-09-30 14:36:00,305 - util.py[DEBUG]: Running command ['blkid', '-tTYPE=vfat', '-odevice'] with allowed return codes [0, 2] (shell=False, capture=True)
2013-09-30 14:36:00,330 - util.py[DEBUG]: Running command ['blkid', '-tTYPE=iso9660', '-odevice'] with allowed return codes [0, 2] (shell=False, capture=True)
2013-09-30 14:36:00,396 - util.py[DEBUG]: Running command ['blkid', '-tLABEL=config-2', '-odevice'] with allowed return codes [0, 2] (shell=False, capture=True)
2013-09-30 14:36:00,460 - __init__.py[DEBUG]: Seeing if we can get any data from <class 'cloudinit.sources.DataSourceOVF.DataSourceOVF'>
2013-09-30 14:36:00,461 - util.py[DEBUG]: Reading from /proc/mounts (quiet=False)
2013-09-30 14:36:00,461 - util.py[DEBUG]: Read 850 bytes from /proc/mounts
2013-09-30 14:36:00,462 - util.py[DEBUG]: Fetched {'none': {'mountpoint': '/run/user', 'opts': 'rw,nosuid,nodev,noexec,relatime,size=102400k,mode=755', 'fstype': 'tmpfs'}, 'devpts': {'mountpoint': '/dev/pts', 'opts': 'rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000', 'fstype': 'devpts'}, '/dev/disk/by-uuid/ef161361-e0cd-42ef-9cfb-71db599cb980': {'mountpoint': '/', 'opts': 'rw,relatime,data=ordered', 'fstype': 'ext4'}, 'sysfs': {'mountpoint': '/sys', 'opts': 'rw,nosuid,nodev,noexec,relatime', 'fstype': 'sysfs'}, 'udev': {'mountpoint': '/dev', 'opts': 'rw,relatime,size=246792k,nr_inodes=61698,mode=755', 'fstype': 'devtmpfs'}, 'tmpfs': {'mountpoint': '/run', 'opts': 'rw,nosuid,noexec,relatime,size=50296k,mode=755', 'fstype': 'tmpfs'}, 'proc': {'mountpoint': '/proc', 'opts': 'rw,nosuid,nodev,noexec,relatime', 'fstype': 'proc'}, 'rootfs': {'mountpoint': '/', 'opts': 'rw', 'fstype': 'rootfs'}} mounts from /pr...

[Ben Howard (darkmuggle-deactivatedaccount)]

Marking as fix released. Latest images handle this nicely.

[David Eyk (david-eyk)]

I'm not entirely sure if it's the same issue, but I'm seeing something very similar on the latest builds of precise and trusty at http://cloud-images.ubuntu.com/vagrant/. On the first boot, ssh is unreachable and provisioning fails. After halting the VM and subsequently booting it again, ssh is reachable.