Re: dropbear and new host keys?
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 when a user wants to replace the current keys for some reason. > Ideally the > next new session should read the new keys automatically. > > 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 ? > W.r.t -R option, will it dectect a bad key and regenerate a new one ? One problem we have with using -R is that we need to convert dropbear keys to openssh format as well and I cannot see a way to automatically trigger dropbearconvert etc. if we do use -R, is there a way? Jocke
Re: dropbear and new host keys?
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 the -R option. >> >> It's not first boot :( >> This is when a user wants to replace the current keys for some reason. >> Ideally the >> next new session should read the new keys automatically. >> >> 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 ? >> > > W.r.t -R option, will it dectect a bad key and regenerate a new one ? > One problem we have with using -R is that we need to convert dropbear keys to > openssh > format as well and I cannot see a way to automatically trigger > dropbearconvert etc. > if we do use -R, is there a way? > > Jocke Can you use brute force ? Kill the sshd that should cause a restart of the daemon no matter what (killall -9 sshd) re, wh
Re: dropbear and new host keys?
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 restart it without disconnecting everyone. Geoff
Re: dropbear and new host keys?
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 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
Re: dropbear and new host keys?
> 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 man in the middle attack because it cannot verify the host since the hostkey is changed. 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 +, 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 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 >
Re: dropbear and new host keys?
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 > wrote: > > 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 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 > >
