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
On Tue, 15 Oct 2019 at 15:30, Matt Johnston wrote:
> I think regardless of what Dropbear's doing with pipes (closed sessions etc),
> there is probably something wrong with the Linux kernel.
> As far as I know userspace can't trigger D state even intentionally (I'd be
> interested if anyone
On Mon, 15 Jun 2020 at 16:52, Matt Johnston wrote:
> This release also supports rsa-sha2 signatures which will be
> required by OpenSSH in the near future - rsa with sha1 will
> be disabled. This doesn't require any change to
> hostkey/authorized_keys files.
>
Apologies if I'm being obtuse;
On Wed, 17 Jun 2020 at 13:19, I wrote:
> Apologies if I'm being obtuse; with newer version of openssh client the
> new dropbear won't accept rsa keys:
>
Just to update the list in case anyone else hits the same problem I did,
the issue was caused by running an out-of-date version of Pageant (the
On Tue, 9 Mar 2021 at 15:43, Kazuo Kuroi wrote:
> That's a good suggestion. but I suggest that if your code can't run on
> UNIX platforms that it would need an include guard against it.
I completely understand your concern.
I would hope that the changes would be system-agnostic: the idea would
Hi
I appreciate that there's an compile-time option
DROPBEAR_SVR_MULTIUSER=0 to skip the setuid/gid sections, but can I
make a humble suggestion that we fail gracefully if someone* runs a
dropbear that _doesn't_ have that option configured on a linux kernel
that's compiled single-user.
*Not me,
On Wed, 10 Mar 2021 at 12:14, Hans Harder wrote:
> Indeed that is the correct question, because you can easily do
>
> #if DROPBEAR_SVR_MULTIUSER
>if (getuid() != ses.authstate.pw_uid) {
> setgid and setuid part
>}
> #endif
Well yes, if you're confident that setgid() and
Removing the banner file stops subsequent logins. This is a
significant behaviour change (in the past, you could run dropbear,
then delete the banner file).
First, I'm pretty sure failing to open the banner should not terminate
the inbound connections. Second, it would have been nice to mention
Hi
Not sure whether you care, given the age of the system involved, but I
had to build dropbear for an ancient system with no support for the
open() O_CLOEXEC flag, and it moaned at me.
My quick and dirty patch is attached. Feel free to ignore if you like:
I'm unlikely to ever build anything for
