On Wed, 2019-12-11 at 18:00 +0100, Joakim Tjernlund wrote:
> On Wed, 2019-12-11 at 23:53 +0800, Matt Johnston wrote:
> > Hi Joakim,
> >
> > The server needs to be stopped and restarted. If this is for new keys at
> > first-boot you could look at the -R option.
>
> It's not first boot :(
> This is
Am 12.12.2019 13:01, schrieb Joakim Tjernlund:
> On Wed, 2019-12-11 at 18:00 +0100, Joakim Tjernlund wrote:
>> On Wed, 2019-12-11 at 23:53 +0800, Matt Johnston wrote:
>>> Hi Joakim,
>>>
>>> The server needs to be stopped and restarted. If this is for new keys at
>>> first-boot you could look at
On Wed, 11 Dec 2019 at 17:00, Joakim Tjernlund
wrote:
> In out case we cannot just restart dropbear and rebooting just for new keys
> is not an option either.
> Could dropbear gain automatic reread of keys ?
You know if you kill the parent process the child processes keep
running? So you can res
On Thu, 2019-12-12 at 13:31 +, Geoff Winkless wrote:
>
> On Wed, 11 Dec 2019 at 17:00, Joakim Tjernlund
> wrote:
> > In out case we cannot just restart dropbear and rebooting just for new keys
> > is not an option either.
> > Could dropbear gain automatic reread of keys ?
>
> You know if yo
> The bigger issue here is why not reread keys at every new session? That
seems to like the right thing to do in any case?
Performance...
Why should you do that.
You should not change your host keys everytime, because the connecting
client will have a conflict and get a warning about a possible
On Thu, 2019-12-12 at 18:34 +0100, Hans Harder wrote:
>
> > The bigger issue here is why not reread keys at every new session? That
> > seems to like the right thing to do in any case?
>
> Performance...
My text above was badly worded, should be: reread if keyfiles has changed.
> Why should