ssh host key
cover ssh host key
I had problems under qemu with getting the ssh host key generated (not enough entropy). That problem still persists, but perhaps is less severe on real hardware and for me. Having the same ssh host key for the qemu test machine was good enough for me and potentially also others, so here's an utility class which helps achieving that.
The following changes since commit a7d8eaef04c9dd6ede8d4efd8c4b776efbe3c767:
shadow: split files needed for PAM use into separate package (2015-04-09 19:48:04 +0100)
are available in the git repository at:
git://github.com/pohly/openembedded-core master
https://github.com/pohly/openembedded-core/tree/master
Patrick Ohly (1):
rootfsdebugfiles.bbclass: quick-and-dirty installation of additional
files
meta/classes/rootfsdebugfiles.bbclass | 36 +++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 meta/classes/rootfsdebugfiles.bbclass
Signature · 1 line
1.8.4.5
PATCH 1/1 rootfsdebugfiles.bbclass: quick-and-dirty installation of additional files
The main motivation for this class was the observation that
a) a core-image can hang under qemu when the kernel does not have enough entropy to generate the ssh host key
b) ssh complains about changing ssh host key files when rebooting the same machine with different images
For debugging it is okay to reuse an ssh host key generated on the device before. There may be also similar use cases, so the class is generic enough to also copy more than one file or directory, with dropbear_rsa_host_key given as example.
The documentation and naming of the class makes it clear that it should not be used for production images.
--- meta/classes/rootfsdebugfiles.bbclass | 36 +++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 meta/classes/rootfsdebugfiles.bbclass
meta/classes/rootfsdebugfiles.bbclass new file +36 -0
@@ -0,0 +1,36 @@ +# This class installs additional files found on the build host +# directly into the rootfs. +# +# One use case is to install a constant ssh host key in +# an image that gets created for just one machine. This +# solves two issues: +# - host key generation on the device can stall when the +# kernel has not gathered enough entropy yet (seen in practice +# under qemu) +# - ssh complains by default when the host key changes +# +# For dropbear, with the ssh host key store along side the local.conf: +# 1. Extend local.conf: +# INHERIT += "rootfsdebugfiles" +# ROOTFS_DEBUG_FILES += "${TOPDIR}/conf/dropbear_rsa_host_key ${IMAGE_ROOTFS}/etc/dropbear/dropbear_rsa_host_key ;" +# 2. Boot the image once, copy the dropbear_rsa_host_key from +# the device into your build conf directory. +# +# Do not use for production images! It bypasses several +# core build mechanisms (updating the image when one +# of the files changes, license tracking in the image +# manifest, ...). + +ROOTFS_DEBUG_FILES ?= "" +ROOTFS_DEBUG_FILES[doc] = "Lists additional files or directories to be installed with 'cp -a' in the format 'source1 target1;source2 target2;...'" + +ROOTFS_POSTPROCESS_COMMAND += "rootfs_debug_files ;" +rootfs_debug_files () { + #!/bin/sh -e + echo "${ROOTFS_DEBUG_FILES}" | sed -e 's/;/\n/g' | while read source target; do + if [ -e "$source" ]; then + mkdir -p $(dirname $target) + cp -a $source $target + fi + done +}
Signature · 1 line
1.8.4.5
Re: [PATCH 1/1] rootfsdebugfiles.bbclass: quick-and-dirty installation of additional files
Quoted 13 lines · Patrick Ohly
The main motivation for this class was the observation that
a) a core-image can hang under qemu when the kernel does not have enough entropy to generate the ssh host key
b) ssh complains about changing ssh host key files when rebooting the same machine with different imagesFor debugging it is okay to reuse an ssh host key generated on the device before. There may be also similar use cases, so the class is generic enough to
also copy more than one file or directory, withdropbear_rsa_host_keygiven as
example.
Quoted 5 lines
The documentation and naming of the class makes it clear that it should not be used for production images.
Signed-off-by Patrick Ohly <[email protected]>
Freescale's merge-files recipe may be worth looking at as an alternative to this.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics
Hi Patrick,
you should have a look at HAVEGED. It's an entropy generator for headless machines. It should also help you on qemu devices.
Regards,
Sven
Am 13.04.2015 um 17:44 schrieb Patrick Ohly:
Quoted 23 lines
I had problems under qemu with getting the ssh host key generated (not enough entropy). That problem still persists, but perhaps is less severe on real hardware and for me. Having the same ssh host key for the qemu test machine was good enough for me and potentially also others, so here's an utility class which helps achieving that.
The following changes since commit
a7d8eaef04c9dd6ede8d4efd8c4b776efbe3c767:shadow: split files needed for PAM use into separate package (2015-04-09 19:48:04 +0100)
are available in the git repository at:
git://github.com/pohly/openembedded-coremaster
https://github.com/pohly/openembedded-core/tree/masterPatrick Ohly (1):
rootfsdebugfiles.bbclass: quick-and-dirty installation of additional
filesmeta/classes/rootfsdebugfiles.bbclass | 36 +++++++++++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 meta/classes/rootfsdebugfiles.bbclass
Re: [PATCH 1/1] rootfsdebugfiles.bbclass: quick-and-dirty installation of additional files
In reply to Christopher LarsonQuoted 17 lines · Christopher Larson
On Mon, Apr 13, 2015 at 8:44 AM, Patrick Ohly <[email protected]> wrote:
The main motivation for this class was the observation that
a) a core-image can hang under qemu when the kernel does not have enough entropy to generate the ssh host key
b) ssh complains about changing ssh host key files when rebooting the same machine with different imagesFor debugging it is okay to reuse an ssh host key generated on the device
before. There may be also similar use cases, so the class is generic enough to
also copy more than one file or directory, withdropbear_rsa_host_keygiven as
example.
Quoted 8 lines
The documentation and naming of the class makes it clear that it
should not be used for production images.Signed-off-by Patrick Ohly <[email protected]>Freescale's merge-files recipe may be worth looking at as an alternative to this.
Thanks for mentioning it. Yes, that's also a way to do it. It seems a bit more complicated to set up (all files must be in a common "merge" directory) and does not seem to support sub-directories (-maxdepth 1), so it is a bit less flexible than the ROOTFS_DEBUG_FILES that I was proposing. On the other hand, the files get packaged properly (well, if one is careful about adapting the default MIT license as needed).
For my use case, I still prefer the quick-and-dirty approach.
Signature · 6 lines
Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter.
Re: [PATCH 1/1] rootfsdebugfiles.bbclass: quick-and-dirty installation of additional files
Quoted 27 lines · Patrick Ohly
Quoted 17 lines · Christopher Larson
On Mon, Apr 13, 2015 at 8:44 AM, Patrick Ohly <[email protected]> wrote:
The main motivation for this class was the observation that
a) a core-image can hang under qemu when the kernel does not have enough entropy to generate the ssh host key
b) ssh complains about changing ssh host key files when rebooting the same machine with different imagesFor debugging it is okay to reuse an ssh host key generated on the device
before. There may be also similar use cases, so the class is generic enough to
also copy more than one file or directory, withdropbear_rsa_host_keygiven as
example.Quoted 8 lines
The documentation and naming of the class makes it clear that it
should not be used for production images.Signed-off-by Patrick Ohly <[email protected]>Freescale's merge-files recipe may be worth looking at as an alternative to this.
Quoted 8 lines
Thanks for mentioning it. Yes, that's also a way to do it. It seems a bit more complicated to set up (all files must be in a common "merge" directory) and does not seem to support sub-directories (-maxdepth 1), so it is a bit less flexible than the
ROOTFS_DEBUG_FILESthat I was proposing. On the other hand, the files get packaged properly (well, if one is careful about adapting the default MIT license as needed).For my use case, I still prefer the quick-and-dirty approach.
Indeed, both approaches have value, depending on one's needs, I think.
Signature · 5 lines
Christopher Larson clarson at kergoth dot com Founder - BitBake, OpenEmbedded, OpenZaurus Maintainer - Tslib Senior Software Engineer, Mentor Graphics