Hello,
On Wed, Dec 12, 2018 at 05:14:03PM +0100, Uwe Kleine-König wrote:
> [ 1057.771583] random: crng init done
> [ 1057.774739] random: 7 urandom warning(s) missed due to ratelimiting
>
> I'm not aware the machine has a random number generator, so the solutions
> presented here up
On Sun, Oct 28, 2018 at 11:41:14AM +0100, Bernhard Übelacker wrote:
> Dear Maintainer,
> just some more information, because I think I see this
> difference in my qemu buster amd64 VM too.
>
> Before I could ssh into that machine just after some seconds.
>
> Now it takes some time until that
For people using libvirt, I've found that adding the following to a
domain solves this problem.
/dev/urandom
Thanks for the useful pointer in this direction Ted.
--
~ ry
Package: openssh-server
Version: 1:7.9p1-4
Followup-For: Bug #912087
Hi,
Theodore Y. Ts'o wrote:
> The first is virtio_rng, since the assumption is if you are using a VM, you
> had better trust the host infrastructure or you have much worse problems.
Doesn't that apply to non-virtual hardware
On 2018-11-01 19:50:35 [-0400], Theodore Y. Ts'o wrote:
> On Thu, Nov 01, 2018 at 11:18:14PM +0100, Sebastian Andrzej Siewior wrote:
> > Okay. So you wrote what can be done for a system with HW-RNG/kvm. On
> > bare metal with nothing fancy I have:
> > [3.544985] systemd[1]: systemd 239 running
On 2018-10-30 21:51, Theodore Y. Ts'o wrote:
> On Tue, Oct 30, 2018 at 07:37:23PM +0100, Kurt Roeckx wrote:
>>
>> So are you saying that the /var/lib/random/seed is untrusted, and
>> should never be used, and we should always wait for fresh entropy?
>>
[...]
>
> In any case, if Debian wants to
On Fri, Nov 02, 2018 at 01:24:25AM +0100, Kurt Roeckx wrote:
> Anyway, on my laptop I get:
> [ 12.675935] random: crng init done
>
> If the TPM is enabled, I also have an /etc/hwrng, but rng-tools is
> started later after the init is done.
>
> On my desktop (with a chaos key attached)
> [
On Thu, Nov 01, 2018 at 07:50:35PM -0400, Theodore Y. Ts'o wrote:
> On Thu, Nov 01, 2018 at 11:18:14PM +0100, Sebastian Andrzej Siewior wrote:
> > Okay. So you wrote what can be done for a system with HW-RNG/kvm. On
> > bare metal with nothing fancy I have:
> > [3.544985] systemd[1]: systemd
On Thu, Nov 01, 2018 at 11:18:14PM +0100, Sebastian Andrzej Siewior wrote:
> Okay. So you wrote what can be done for a system with HW-RNG/kvm. On
> bare metal with nothing fancy I have:
> [3.544985] systemd[1]: systemd 239 running in system mode. (+PAM…
> [ 10.363377] r8169 :05:00.0
On 2018-10-31 18:41:06 [-0400], Theodore Y. Ts'o wrote:
> On Wed, Oct 31, 2018 at 11:21:59AM +, Sebastian Andrzej Siewior wrote:
> > On October 30, 2018 8:51:36 PM UTC, "Theodore Y. Ts'o"
> > wrote:
> > >
> > >So it's complicated. It's not a binary trusted/untrusted sort of
> > >thing.
>
On Wed, Oct 31, 2018 at 11:21:59AM +, Sebastian Andrzej Siewior wrote:
> On October 30, 2018 8:51:36 PM UTC, "Theodore Y. Ts'o" wrote:
> >
> >So it's complicated. It's not a binary trusted/untrusted sort of
> >thing.
>
> What about RNDRESEEDCRNG? Would it be reasonable to issue it after
On October 30, 2018 8:51:36 PM UTC, "Theodore Y. Ts'o" wrote:
>
>So it's complicated. It's not a binary trusted/untrusted sort of
>thing.
What about RNDRESEEDCRNG? Would it be reasonable to issue it after writing the
seed as part of the boot process?
>Cheers,
>
>
On Tue, Oct 30, 2018 at 07:37:23PM +0100, Kurt Roeckx wrote:
>
> So are you saying that the /var/lib/random/seed is untrusted, and
> should never be used, and we should always wait for fresh entropy?
>
> Anyway, I think if an attacker somehow has access to that file,
> you have much more serious
On Tue, Oct 30, 2018 at 10:15:44AM -0400, Theodore Y. Ts'o wrote:
> On Tue, Oct 30, 2018 at 01:18:08AM +0100, Sebastian Andrzej Siewior wrote:
> > Using ioctl(/dev/urandom, RNDADDENTROPY, ) instead writting to
> > /dev/urandom would do the trick. Or using RNDADDTOENTCNT to increment
> > the
On Tue, Oct 30, 2018 at 01:18:08AM +0100, Sebastian Andrzej Siewior wrote:
> Using ioctl(/dev/urandom, RNDADDENTROPY, ) instead writting to
> /dev/urandom would do the trick. Or using RNDADDTOENTCNT to increment
> the entropy count after it was written. Those two are documented in
> random(4). Or
On Tue, 30 Oct 2018 01:18:08 +0100 Sebastian Andrzej Siewior
wrote:
> Using ioctl(/dev/urandom, RNDADDENTROPY, ) instead writting to
> /dev/urandom would do the trick. Or using RNDADDTOENTCNT to increment
> the entropy count after it was written. Those two are documented in
> random(4). Or
On 2018-10-29 23:33:34 [+0100], Kurt Roeckx wrote:
> On Mon, Oct 29, 2018 at 09:58:20PM +0100, Sebastian Andrzej Siewior wrote:
> > On 2018-10-29 18:22:08 [+0100], Kurt Roeckx wrote:
> > > So I believe this is not an openssl issue, but something in the
> > > order that the kernel's RNG is
On Mon, Oct 29, 2018 at 09:58:20PM +0100, Sebastian Andrzej Siewior wrote:
> On 2018-10-29 18:22:08 [+0100], Kurt Roeckx wrote:
> > So I believe this is not an openssl issue, but something in the
> > order that the kernel's RNG is initialized and openssh is started.
> > Potentionally the RNG isn't
On 2018-10-29 18:22:08 [+0100], Kurt Roeckx wrote:
> So I believe this is not an openssl issue, but something in the
> order that the kernel's RNG is initialized and openssh is started.
> Potentionally the RNG isn't initialized at all and you actually
> have to wait for the kernel to get it's
On Mon, Oct 29, 2018 at 07:11:17PM +0100, Michael Biebl wrote:
> On Mon, 29 Oct 2018 18:22:08 +0100 Kurt Roeckx wrote:
> > reassign 912087 openssh-server,systemd
> > thanks
> >
> > On Mon, Oct 29, 2018 at 08:38:15AM +0100, Kurt Roeckx wrote:
> > > On Mon, Oct 29, 2018 at 12:28:15AM +, Colin
reassign -1 openssl 1.1.1-1
On Mon, 29 Oct 2018 18:22:08 +0100 Kurt Roeckx wrote:
> reassign 912087 openssh-server,systemd
> thanks
>
> On Mon, Oct 29, 2018 at 08:38:15AM +0100, Kurt Roeckx wrote:
> > On Mon, Oct 29, 2018 at 12:28:15AM +, Colin Watson wrote:
> > > Reassigning to OpenSSL -
reassign 912087 openssh-server,systemd
thanks
On Mon, Oct 29, 2018 at 08:38:15AM +0100, Kurt Roeckx wrote:
> On Mon, Oct 29, 2018 at 12:28:15AM +, Colin Watson wrote:
> > Reassigning to OpenSSL - could the OpenSSL maintainers please have a
> > look and advise what's best to do? (See the
On Mon, Oct 29, 2018 at 12:28:15AM +, Colin Watson wrote:
> Reassigning to OpenSSL - could the OpenSSL maintainers please have a
> look and advise what's best to do? (See the start of the bug, reporting
> a delay of more than one minute in system boot in some cases, mainly
> waiting for sshd
Package: openssl
Version: 1.1.1-1
Followup-For: Bug #912087
Now that by bug report has been switched to the openssl package, I would like
to add that after seeing the above post about entropy, I installed haveged and
now openssh-server starts in a fraction of the mentioned time.
On top of that,
Control: reassign -1 openssl 1.1.1-1
Control: affects -1 openssh
On Mon, Oct 29, 2018 at 12:48:32AM +0100, Bernhard Übelacker wrote:
> Am 28.10.2018 um 19:23 schrieb Colin Watson:
> > Thanks for the investigation. (Note also that the OpenSSH version in
> > question is the one that switched from
Am 28.10.2018 um 19:23 schrieb Colin Watson:
>
> Thanks for the investigation. (Note also that the OpenSSH version in
> question is the one that switched from OpenSSL 1.0 to 1.1, which was a
> big change.)
>
> There were some significant changes in this area in OpenSSL 1.1.1.
> Would it be
On Sun, Oct 28, 2018 at 11:41:14AM +0100, Bernhard Übelacker wrote:
> Now it takes some time until that line "random: crng init done"
> appears in dmesg.
> With logging in in the qemu window this line appears just after a
> few seconds, when just trying via ssh it takes much longer.
>
>
> I
Dear Maintainer,
just some more information, because I think I see this
difference in my qemu buster amd64 VM too.
Before I could ssh into that machine just after some seconds.
Now it takes some time until that line "random: crng init done"
appears in dmesg.
With logging in in the qemu window
Package: openssh-server
Version: 1:7.9p1-1
Severity: normal
Dear Maintainer,
After yesterdays upgrade to 7.9p1 in testing, openssh-server delays my system's
boot by quite some time.
In fact, it is always the first and slowest to start process in systemd-analyze
blame, with times varying from <
29 matches
Mail list logo
