Bug 1415955 - Ubuntu 14 doesn't generate ssh host keys during first boot
Summary: Ubuntu 14 doesn't generate ssh host keys during first boot
Keywords:
Status: NEW
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-24 08:33 UTC by Georg Sauthoff
Modified: 2019-01-28 15:13 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Embargoed:


Attachments (Terms of Use)

Description Georg Sauthoff 2017-01-24 08:33:04 UTC
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

Comment 1 Pino Toscano 2017-01-24 09:04:28 UTC
(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?

Comment 2 Richard W.M. Jones 2017-01-24 13:26:24 UTC
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.

Comment 3 Georg Sauthoff 2017-01-24 22:05:38 UTC
(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

Comment 4 Richard W.M. Jones 2017-01-24 22:15:59 UTC
(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.

Comment 5 Alexander E. Patrakov 2019-01-13 19:42:19 UTC
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?

Comment 6 Richard W.M. Jones 2019-01-14 12:31:54 UTC
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.

Comment 7 Alexander E. Patrakov 2019-01-28 12:47:07 UTC
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.

Comment 8 Richard W.M. Jones 2019-01-28 15:13:42 UTC
Use virt-customize?  It's designed for this and it doesn't do a full sysprep.

http://libguestfs.org/virt-customize.1.html


Note You need to log in before you can comment on or make changes to this bug.