<div dir="ltr"><div dir="ltr">> 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? <br></div><div dir="ltr"><br></div><div>Performance...</div><div>Why should you do that.</div><div>You should not change your host keys everytime, because the connecting client will have a conflict and get a warning about a possible man in the middle attack because it cannot verify the host since the hostkey is changed.</div><div><br></div><div>Simple way is to generate the new hostkeys, kill the main dropbear and start it again.</div><div>Should be a very simple script... and the current running sessions are not affected.</div><div><br></div><div>Hans</div><div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Dec 12, 2019 at 2:58 PM Joakim Tjernlund <<a href="mailto:Joakim.Tjernlund@infinera.com">Joakim.Tjernlund@infinera.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 2019-12-12 at 13:31 +0000, Geoff Winkless wrote:<br>
> <br>
> On Wed, 11 Dec 2019 at 17:00, Joakim Tjernlund<br>
> <<a href="mailto:Joakim.Tjernlund@infinera.com" target="_blank">Joakim.Tjernlund@infinera.com</a>> wrote:<br>
> > In out case we cannot just restart dropbear and rebooting just for new keys is not an option either.<br>
> > Could dropbear gain automatic reread of keys ?<br>
> <br>
> You know if you kill the parent process the child processes keep<br>
> running? So you can restart it without disconnecting everyone.<br>
<br>
Yes, but in our case dropbear start/stop script is connected with several other daemons, but yes it can be<br>
worked around.<br>
<br>
The bigger issue here is why not reread keys at every new session? That seems to like the<br>
right thing to do in any case? <br>
<br>
Jocke<br>
</blockquote></div></div>