Re: dropbear and new host keys?
On Mon, 2019-12-16 at 22:16 +0800, Matt Johnston wrote: > > > On Fri 13/12/2019, at 2:14 am, Joakim Tjernlund > > wrote: > > > > 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... > > I don't _think_ there would be any performance problem reloading key files > for each session - compared with the key exchange it's not compute intensive. > It's better to keep it simple rather than introduce cache invalidation by > file timestamps where it isn't needed. I'd been considering moving non-inetd > dropbear to use fork/self-exec instead of plain fork() for improved address > space randomisation, that would probably require loading keys each time too. > > That said if I were in the same situation I'd just run "kill `cat > /var/run/dropbear.pid; service dropbear start" or similar when writing > keyfiles - job done. > Well, these days people wants to regen both host keys and certificates every now and then. I think the community would appreciate if dropbear picked up new keys automatically without being forced to an inetd model. You already have an option to generate keys on the fly(-R) Jocke
Re: dropbear and new host keys?
> On Fri 13/12/2019, at 2:14 am, Joakim Tjernlund > wrote: > > 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... I don't _think_ there would be any performance problem reloading key files for each session - compared with the key exchange it's not compute intensive. It's better to keep it simple rather than introduce cache invalidation by file timestamps where it isn't needed. I'd been considering moving non-inetd dropbear to use fork/self-exec instead of plain fork() for improved address space randomisation, that would probably require loading keys each time too. That said if I were in the same situation I'd just run "kill `cat /var/run/dropbear.pid; service dropbear start" or similar when writing keyfiles - job done. Cheers, Matt
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 > >
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 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 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?
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, 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?
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 ? Jocke > > Cheers, > Matt > > On Wed, Dec 11, 2019 at 03:38:36PM +, Joakim Tjernlund wrote: > > Is there a way to tell a running dropbear server to reread host keys if the > > keys has changed? > > > > Jocke
Re: dropbear and new host keys?
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. Cheers, Matt On Wed, Dec 11, 2019 at 03:38:36PM +, Joakim Tjernlund wrote: > Is there a way to tell a running dropbear server to reread host keys if the > keys has changed? > > Jocke
dropbear and new host keys?
Is there a way to tell a running dropbear server to reread host keys if the keys has changed? Jocke
