Hi,

If I have a ro root, I disable rconce completely and implement something 
comparable for a data partition
and mount the device unique keys to /etc/ssh/.
rconce mount your ro root rw and stores something, at least the "done" marker 
file, to your root.
I assume you are fine with this changes and just want to keep the key over 
updates and therefor you should really consider a data/config partition.
You may also generate the keys in production and mount the config partition 
read-only to /etc/ssh/.
But do NOT deploy the same key to different devices.

Regards, Denis

Am Montag, den 16.11.2020, 11:32 +0100 schrieb Michael Olbrich:
> On Mon, Nov 16, 2020 at 10:45:07AM +0100, Artur Wiebe wrote:
> > On Monday, November 16, 2020 10:36 CET, Michael Olbrich 
> > <[email protected]> wrote:
> > > On Sun, Nov 15, 2020 at 06:08:56PM +0100, Roland Hieber wrote:
> > > > On Sun, Nov 15, 2020 at 11:06:12AM +0100, Ladislav Michl wrote:
> > > > > On Sat, Nov 14, 2020 at 09:34:47PM +0100, Roland Hieber wrote:
> > > > > > On Fri, Nov 13, 2020 at 06:46:48PM +0100, Ladislav Michl wrote:
> > > > > > > On Fri, Nov 13, 2020 at 03:19:55PM +0100, Artur Wiebe wrote:
> > > > > > > > How can openssh.postinst be disabled from within the rule files?
> > > > > > >
> > > > > > > The very same could be achieved with symlink in your BSP:
> > > > > > > projectroot/etc/rc.once.d/openssh -> /dev/null
> > > > > >
> > > > > > I don't understand why you want to disable this. The SSH server 
> > > > > > will not
> > > > > > start without host keys. Or do you want to install a static version 
> > > > > > of
> > > > > > the host keys generated at build time?
> > > > >
> > > > > Yes, keys are static, generated at build time. Root filesystem is
> > > > > read-only.
> > > > >
> > > > > > If so, there should be an option for this. But for now, in my 
> > > > > > opinion,
> > > > > > disabling OPENSSH_SSHD_GENKEYS will just lead to a broken SSH 
> > > > > > server.
> > > > >
> > > > > As this is easy to solve at BSP level I never thought it could
> > > > > be a thing :)
> > > >
> > > > OK, but at least I would mention it in the kconfig help text. The
> > >
> > > Ack.
> > >
> > > > openssh recipe could also just pick up /etc/ssh/ssh_host_*_key via
> > > > install_alternative if this option is disabled.
> > >
> > > No. Shared ssh server keys are a bad idea. That's not something I want to
> > > merge upstream.
> >
> > This was also my concern...
> >
> > >
> > > But there are other use-cases to not use rc-once, e.g. if the server keys
> > > are generated during provisioning. And not selecting rc-once in this case
> > > makes sense, so this is acceptable im general.
> >
> > I still need a way to disable openssh.postinst if OPENSSH_SSHD_GENKEYS is 
> > not set.
>
> Hmmm, right. In the BSP, a /dev/null symlinks works for this as well, but
> we currently don't have a way to not install the postinst script. We could
> do something like this (untested):
>
> $(call install_script_replace, openssh, postinst, @RC_ONCE@, \
> $(call ptx/ifdef, PTXCONF_OPENSSH_SSHD_GENKEYS,,#))
>
> And in rules/openssh.postinst:
>
> #!/bin/sh
> @RC_ONCE@$DESTDIR/usr/sbin/enable-rc-once openssh
>
> This way the script may be installed, but it will do nothing. If
> PTXCONF_OPENSSH_SSHD_GENKEYS is disabled.
>
> Michael
>
Diehl Connectivity Solutions GmbH
Geschäftsführung: Horst Leonberger
Sitz der Gesellschaft: Nürnberg - Registergericht: Amtsgericht
Nürnberg: HRB 32315

________________________________

Der Inhalt der vorstehenden E-Mail ist nicht rechtlich bindend. Diese E-Mail 
enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen.
Informieren Sie uns bitte, wenn Sie diese E-Mail faelschlicherweise erhalten 
haben. Bitte loeschen Sie in diesem Fall die Nachricht.
Jede unerlaubte Form der Reproduktion, Bekanntgabe, Aenderung, Verteilung 
und/oder Publikation dieser E-Mail ist strengstens untersagt.

- Informationen zum Datenschutz, insbesondere zu Ihren Rechten, erhalten Sie 
unter:

https://www.diehl.com/group/de/transparenz-und-informationspflichten/

The contents of the above mentioned e-mail is not legally binding. This e-mail 
contains confidential and/or legally protected information. Please inform us if 
you have received this e-mail by
mistake and delete it in such a case. Each unauthorized reproduction, 
disclosure, alteration, distribution and/or publication of this e-mail is 
strictly prohibited.

- For general information on data protection and your respective rights please 
visit:

https://www.diehl.com/group/en/transparency-and-information-obligations/


_______________________________________________
ptxdist mailing list
[email protected]
To unsubscribe, send a mail with subject "unsubscribe" to 
[email protected]

Reply via email to