From: Mike Looijmans <mike.looijmans@topic.nl>
To: Martin Jansa <martin.jansa@gmail.com>
Cc: openembedded-core@lists.openembedded.org, Zhangle.Yang@windriver.com
Subject: Re: [PATCH 9/9] Generate ssh keys at rootfs creation time in case of a read-only rootfs
Date: Fri, 26 Jul 2013 13:08:16 +0200 [thread overview]
Message-ID: <51F258A0.9090007@topic.nl> (raw)
In-Reply-To: <20130726092812.GD3280@jama>
On 07/26/2013 11:28 AM, Martin Jansa wrote:
> On Fri, Jul 26, 2013 at 03:39:36PM +0800, Qi.Chen@windriver.com wrote:
>> From: Chen Qi <Qi.Chen@windriver.com>
>>
>> To avoid generating ssh keys every time a system with read-only rootfs
>> starts, we generate ssh keys at rootfs creation time.
>>
>> This change only has effect for systems with read-only rootfs.
>
> I'm not sure if having the same keys on all devices installed from the
> same image is always desired behavior, imho it should be controlled by
> another variable, because some people want read-only rootfs and keys
> generated in some other write-able partition.
>
Agree.
I would suggest creating a separate recipe that places a ssh key on the
filesystem. That would be about equally useful, and it gives people a
choice. During development, such a feature is very nice to have, as it
lets the test board keep its current ssh key. It's a recipe that I'd be
happy to contribute. I alread have one that puts my pulic key on the box
so i can safely log in and/or run automated test software with passwords
disabled.
Met vriendelijke groet / kind regards,
Mike Looijmans
TOPIC Embedded Systems
Eindhovenseweg 32-C, NL-5683 KH Best
Postbus 440, NL-5680 AK Best
Telefoon: (+31) – (0)499 - 33.69.79
Telefax: (+31) - (0)499 - 33.69.70
E-mail: mike.looijmans@topic.nl
Website: www.topic.nl
Dit e-mail bericht en de eventueel daarbij behorende bijlagen zijn uitsluitend bestemd voor de geadresseerde, zoals die blijkt uit het e-mail bericht en/of de bijlagen. Er kunnen gegevens met betrekking tot een derde instaan. Indien u als niet-geadresseerde dit bericht en de bijlagen ontvangt, terwijl u niet bevoegd of gemachtigd bent om dit bericht namens de geadresseerde te ontvangen, wordt u verzocht de afzender hierover direct te informeren en het e-mail bericht met de bijlagen te vernietigen. Ieder gebruik van de inhoud van het e-mail bericht, waaronder de daarbij behorende bijlagen, door een ander dan de geadresseerde is onrechtmatig jegens ons dan wel de eventueel in het e-mail bericht of de bijlagen voorkomende andere personen. TOPIC Embedded Systems is niet aansprakelijk voor enigerlei schade voortvloeiend uit het gebruik en/of acceptatie van dit e-mail bericht of de daarbij behorende bijlagen.
The contents of this message, as well as any enclosures, are addressed personally to, and thus solely intended for the addressee. They may contain information regarding a third party. A recipient who is neither the addressee, nor empowered to receive this message on behalf of the addressee, is kindly requested to immediately inform the sender of receipt, and to destroy the message and the enclosures. Any use of the contents of this message and/or the enclosures by any other person than the addressee or person who is empowered to receive this message, is illegal towards the sender and/or the aforementioned third party. TOPIC Embedded Systems is not liable for any damage as a result of the use and/or acceptance of this message and as well as any enclosures.
next prev parent reply other threads:[~2013-07-26 11:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-26 7:39 [PATCH 0/9] Make read-only rootfs work well with live images Qi.Chen
2013-07-26 7:39 ` [PATCH 1/9] init-live.sh: make $ROOT_MOUNT/media writable when necessary Qi.Chen
2013-07-26 7:39 ` [PATCH 2/9] use a uniform way to determine whether rootfs is read-only Qi.Chen
2013-07-26 7:39 ` [PATCH 3/9] udev: remove implicit dependency on initscripts Qi.Chen
2013-07-26 7:39 ` [PATCH 4/9] populate-volatile.sh: use $ROOT_DIR/var/volatile/tmp as TMPDIR Qi.Chen
2013-07-26 7:39 ` [PATCH 5/9] runqemu-internal: fix to start X correctly in live images Qi.Chen
2013-07-26 7:39 ` [PATCH 6/9] initscripts: use a uniform way to handle directories in read-only rootfs Qi.Chen
2013-07-26 7:39 ` [PATCH 7/9] irda-utils: make /etc/sysconfig writable " Qi.Chen
2013-07-26 7:39 ` [PATCH 8/9] lighttpd: make /www diretory " Qi.Chen
2013-07-26 7:39 ` [PATCH 9/9] Generate ssh keys at rootfs creation time in case of a " Qi.Chen
2013-07-26 9:28 ` Martin Jansa
2013-07-26 9:52 ` Phil Blundell
2013-07-26 11:08 ` Mike Looijmans [this message]
2013-07-26 11:22 ` Burton, Ross
2013-07-26 10:39 ` Enrico Scholz
2013-07-29 1:55 ` ChenQi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=51F258A0.9090007@topic.nl \
--to=mike.looijmans@topic.nl \
--cc=Zhangle.Yang@windriver.com \
--cc=martin.jansa@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox