[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    Re: [OE-core] how to *securely* do a remote install of an OE image?
From:       Bryan Evenson <bevenson () melinkcorp ! com>
Date:       2017-02-28 16:52:50
Message-ID: DM5PR05MB295486F29DFC2932E5054801BB560 () DM5PR05MB2954 ! namprd05 ! prod ! outlook ! com
[Download RAW message or body]

Robert,

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> Of Robert P. J. Day
> Sent: Tuesday, February 28, 2017 10:20 AM
> To: Patrick Ohly <patrick.ohly@intel.com>
> Cc: OE Core mailing list <openembedded-core@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@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core


[prev in list] [next in list] [prev in thread] [next in thread]