Description of problem: Trying to log into a ubuntu-14.04 VM (whose image was generated with virt-builder with ssh-inject options) via ssh fails because the VM doesn't have any host keys. Version-Release number of selected component (if applicable): libguestfs-tools-1.34.3-1.fc25.noarch How reproducible: always Steps to Reproduce: 1. call virt-builder like this: virt-builder ubuntu-14.04 --hostname ubuntu14-vm.example.org --firstboot-command 'useradd -m juser' --ssh-inject root:file:$HOME/.ssh/id_ed25519.pub --root-password file:rootpw --size 20G -o ubuntu-14-x86-64-test.img 2. boot via: qemu-system-x86_64 -display curses -enable-kvm -drive file=ubuntu-14-x86-64-test.img,if=virtio,format=raw -m 2048 -net nic,model=virtio,macaddr=a6:bc:de:f0:12:34 -net tap,fd=3 3<>/dev/tap4 3. Actual results: no public-key auth login with the configured key possible Expected results: successful public-key auth login via ssh Additional info: when logging in via the qemu console I can see that no ssh host keys where generated during first boot: $ ls /etc/ssh/ moduli ssh_config sshd_config ssh_import_id (also there are log messages about missing host keys in /var/log/auth.log) After a apt-get update && apt-get dist-upgrade apparently sshd also gets updated and this update does generate the missing ssh host keys. Note that my above virt-builder command line doesn't include the --update Option - the main reason for this: the --update as part of the virt-builder always failed for me with this ubuntu 14 image. PS: Additional paper cuts I noticed with this ubuntu 14 template: - the juser user is created with uid 1001 but its home directory /home/juser is owned by uid 1000 (which is not present in /etc/passwd) - there is no /var/log/installer/initial-status.gz - which is useful when one wants to generate a list of manually installed packages
(In reply to Georg Sauthoff from comment #0) > Trying to log into a ubuntu-14.04 VM (whose image was generated with > virt-builder with ssh-inject options) via ssh fails because the VM doesn't > have any host keys. This is actually documented in the notes of the template: $ virt-builder --notes ubuntu-14.04 Ubuntu 14.04 (Trusty). This is a minimal Ubuntu 14.04 (Trusty) install. Only the openssh-server package is selected in tasksel. The preseed and virt-install scripts that produced this image can be found in the libguestfs source tree: builder/website/ubuntu.preseed builder/website/ubuntu.sh This image does not contain SSH host keys. To regenerate them use: --firstboot-command "dpkg-reconfigure openssh-server" IMPORTANT NOTE: It seems to be impossible to create an Ubuntu >= 14.04 image using preseed without creating a user account. Therefore this image contains a user account 'builder'. I have disabled it, so that people who don't read release notes don't get caught out, but you might still wish to delete it completely. > Note that my above virt-builder command line doesn't include the --update > Option - the main reason for this: the --update as part of the virt-builder > always failed for me with this ubuntu 14 image. Ah I see, apparently udev cannot properly run its postinst when not also running: Setting up udev (204-5ubuntu20.20) ... Installing new version of config file /etc/init/udev-fallback-graphics.conf ... initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused * udev requires hotplug support, not started ...fail! invoke-rc.d: initscript udev, action "restart" failed. dpkg: error processing package udev (--configure): subprocess installed post-installation script returned error exit status 1 Maybe updating the template could avoid that. > PS: Additional paper cuts I noticed with this ubuntu 14 template: > - the juser user is created with uid 1001 but its home directory /home/juser > is owned by uid 1000 (which is not present in /etc/passwd) UID 1000 is the disabled 'builder' user (see notes of the template). I tried your reproducer, but I got the right behaviour, i.e. user 'builder' with UID 1000 owning /home/builder, and user 'juser' with UID 1001 owning /home/juser. > - there is no /var/log/installer/initial-status.gz - which is useful when > one wants to generate a list of manually installed packages IIRC isn't that something you can get from dpkg/apt directly?
The Ubuntu template could definitely be improved in at least the ways that Pino mentions: (1) Fix the SSH host keys thing. (2) Remove the builder account. The source for this is now: https://github.com/libguestfs/libguestfs/tree/master/builder/templates and patches to fix it are welcome.
(In reply to Pino Toscano from comment #1) > (In reply to Georg Sauthoff from comment #0) [..] > This is actually documented in the notes of the template: > $ virt-builder --notes ubuntu-14.04 > Ubuntu 14.04 (Trusty). [..] > This image does not contain SSH host keys. To regenerate them use: > > --firstboot-command "dpkg-reconfigure openssh-server" Interesting, I looked up many options in the virt-builder man page but never noticed the --notes option. But wouldn't it be great if the template would automatically generate the host keys during first boot, though? I mean as-is, each user has to remember to specify this option just for the Ubuntu template ... Instead the template could issue the above mentioned dpkg-reconfigure or a `ssh-keygen -A` on first boot, by default. [..] > > PS: Additional paper cuts I noticed with this ubuntu 14 template: > > - the juser user is created with uid 1001 but its home directory /home/juser > > is owned by uid 1000 (which is not present in /etc/passwd) [..] > > - there is no /var/log/installer/initial-status.gz - which is useful when > > one wants to generate a list of manually installed packages > IIRC isn't that something you can get from dpkg/apt directly? Not quite. There is `apt-mark showmanual` which excludes all automatically installed depencies. But it still includes all packages that were selected by the installer. Thus on Debian/Ubuntu, to get the true list of user installed packages you need to subtract the packages listed in /var/log/installer/initial-status.gz from the output of `apt-mark showmanual`. See also e.g.: http://askubuntu.com/questions/2389/generating-list-of-manually-installed-packages-and-querying-individual-packages
(In reply to Georg Sauthoff from comment #3) > But wouldn't it be great if the template would automatically > generate the host keys during first boot, though? I mean as-is, > each user has to remember to specify this option just for the > Ubuntu template ... Instead the template could issue the above mentioned > dpkg-reconfigure or a `ssh-keygen -A` on first boot, by default. It would, and the fact that it doesn't is a bug which I don't know how to fix; see comment 2.
Debian maintainers would object if you generate SSH host keys on the first boot, because it is a low-entropy situation. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=500192#40 for more details. Their preferred solution is to generate the keys on the host while sysprepping the guest, not during the first boot. Can the logic "if it is a Debian or Ubuntu guest, generate the keys for it directly on the host and then copy them in" be implemented?
The previous comment is not true for modern guests consuming entropy from /dev/urandom. Also you absolutely must never generate the keys "while sysprepping the guest" if by that you mean when creating the template. If you do that you'll end up with every guest having the same key.
Well, some people (including me) find it convenient to sysprep the clone, not the template, because it's an easy way to set the hostname. I'd even say that the --hostname option sets the precedent for adding operations that do not make sense when applied to a template. I agree that ssh keys should not be in the template, but still think that generating them via virt-sysprep after cloning and printing the public part to stdout is something valid. Obviously, not by default, for the reason that you have already explained. I.e.: Original VM +-> (clone) -> (virt-sysprep --hostname ubuntu1 --new-ssh-keys) -> ubuntu1 (template) |-> (clone) -> (virt-sysprep --hostname ubuntu2 --new-ssh-keys) -> ubuntu2 |-> (clone) -> (virt-sysprep --hostname ubuntu3 --new-ssh-keys) -> ubuntu3 +-> (clone) -> (virt-sysprep --hostname ubuntu4 --new-ssh-keys) -> ubuntu4 ...and ubuntuX VMs should get correct hostnames and new (and known and distinct) ssh keys.
Use virt-customize? It's designed for this and it doesn't do a full sysprep. http://libguestfs.org/virt-customize.1.html