[OE-core] how to *securely* do a remote install of an OE image?

Bryan Evenson bevenson at melinkcorp.com
Tue Feb 28 16:52:50 UTC 2017


Robert,

> -----Original Message-----
> From: openembedded-core-bounces at lists.openembedded.org
> [mailto:openembedded-core-bounces at lists.openembedded.org] On Behalf
> Of Robert P. J. Day
> Sent: Tuesday, February 28, 2017 10:20 AM
> To: Patrick Ohly <patrick.ohly at intel.com>
> Cc: OE Core mailing list <openembedded-core at lists.openembedded.org>
> Subject: Re: [OE-core] how to *securely* do a remote install of an OE image?
> 
> On Tue, 28 Feb 2017, Patrick Ohly wrote:
> 
> > For ssh keys, there's rootfsdebugfiles.bbclass. In local.conf:
> >
> > INHERIT += "rootfsdebugfiles"
> > ROOTFS_DEBUG_FILES += "/home/pohly/.ssh/id_rsa.pub
> ${IMAGE_ROOTFS}/home/root/.ssh/authorized_keys ;"
> >
> > This copies my id_rsa.pub into authorized_keys and thus let's me log
> > into images that I create via ssh.
> 
>   this has definite potential, but i'm about to check whether the
> person/entity that builds the image vs. the person/entity that does the
> install vs. the person that eventually logs into the new system to finish
> setting up could potentially be different.
> 
>   there's a *possibility* that remote installation might be done by a
> distributor, after which someone else might need to do the first login to
> finish the setup, which would complicate things immensely.

Are you talking about burning the initial image or firmware upgrade?  If you're talking about firmware upgrade, another possibility is that you could flip the direction of access.  Instead of remotely logging into each target system, have the target systems remotely login to a centralized server.  That's the approach we took.  We burn the systems with the latest image, and then when we assign them a serial number the system is given a set of SSH keys specific to that serial number.  That set of SSH keys is then used to access the centralized server and obtain the latest firmware.  With this method there's no need to login to the target system, so you can lock it down as much as you want.

Regards,
Bryan

> 
>   i don't know that this is what will happen, but i'm about to run off and ask
> about possibilities.
> 
> rday
> 
> --
> 
> ==========================================================
> ==============
> Robert P. J. Day                                 Ottawa, Ontario, CANADA
>                         http://crashcourse.ca
> 
> Twitter:                                       http://twitter.com/rpjday
> LinkedIn:                               http://ca.linkedin.com/in/rpjday
> ==========================================================
> ==============
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core



More information about the Openembedded-core mailing list