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 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 man in the middle > attack because it cannot verify the host since the hostkey is changed. > Of course not, I didn't say that you should change keys every new session. However, every now and then an admin may regenerate keys and it would be great if dropbear picked up these new keys automatically, it is easy to forget that one also have to restart dropbear ... > Simple way is to generate the new hostkeys, kill the main dropbear and start > it again. > Should be a very simple script... and the current running sessions are not > affected. > > Hans > > > On Thu, Dec 12, 2019 at 2:58 PM Joakim Tjernlund > <joakim.tjernl...@infinera.com> wrote: > > On Thu, 2019-12-12 at 13:31 +0000, Geoff Winkless wrote: > > > > > > On Wed, 11 Dec 2019 at 17:00, Joakim Tjernlund > > > <joakim.tjernl...@infinera.com> 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 restart it without disconnecting everyone. > > > > Yes, but in our case dropbear start/stop script is connected with several > > other daemons, but yes it can be > > worked around. > > > > 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? > > > > Jocke > >
