similar to: openssl 9.3 and openssl 3.1

On Sun, 19 Mar 2023 at 12:25, Nathan Wagner <nw at hydaspes.if.org> wrote: > I'm trying to compile openssh with openssl 3.1 on a linux machine with > kernel 4.15.10. I seem to get stuck at: > > configure: error: OpenSSH has no source of random numbers. Please > configure OpenSSL with an entropy source or re-run configure using one > of the --with-prngd-port or

On Sun, Mar 19, 2023 at 12:57:23PM +1100, Darren Tucker wrote: > On Sun, 19 Mar 2023 at 12:25, Nathan Wagner <nw at hydaspes.if.org> wrote: > Does the OpenSSL self-test ("make tests") pass? Does its basic RNG > function work (eg "openssl rand -base64 9")? And if "openssl rand" > doesn't work, if you strace it what is it trying to do? make

I have a need to have the same OpenSSH binaries run on multiple machines which are administered by different people. That means on Solaris, for example, there will be some with /dev/random, some on which I can run prngd because they'll be installing my binaries as root, and some which will have neither because they will be only installed as non-root. Below is a patch to enable choosing all 3

Over the holidays, I intend to finally rid portable OpenSSH of the builtin entropy collection code. Here's what I intend to do: When init_rng is called, we'll check OpenSSL's RAND_status(). If this indicates that their PRNG is already seeded, we'll do nothing. This effectively detects platforms which have /dev/urandom (or similar) configured into OpenSSL. If OpenSSL isn't

On Thu, 27 Sep 2001 20:41:05 EDT, Damien Miller writes: > On Thu, 27 Sep 2001, Dan Astoorian wrote: > > > > > It would (IMHO) be useful if there were a way to optionally configure > > that code to fall back to the internal entropy gathering routines in the > > event that EGD was not available; as it is, the routines simply fail if > > EGD is unavailable at the

OpenSSL 1.1.0 has deprecated this function. --- configure.ac | 1 + openbsd-compat/openssl-compat.c | 2 ++ openbsd-compat/openssl-compat.h | 4 ++++ 3 files changed, 7 insertions(+) diff --git a/configure.ac b/configure.ac index 3f7fe2cd..db2aade8 100644 --- a/configure.ac +++ b/configure.ac @@ -2710,6 +2710,7 @@ if test "x$openssl" = "xyes" ; then ])

Anyone can locate what was wrong with the below problem on UnixWare 7.1.1 ? The file rand.h was finally found in one of the tests but configure still failed with ... checking for getpagesize... yes checking for OpenSSL directory... configure: error: Could not find working SSLeay / OpenSSL libraries, please install Thanh configure:2302: gcc -o conftest -g -O2 -Wall -I/usr/local/include

Hi, I use openssh-2.9p2 on an i386 LynxOS system. Since LynxOS does not have support for /dev/[u]random, I installed openssh with prngd support. It so happened by accident on installation that prngd.conf got truncated to zero size. With prngd running as such, ssh-keygen just hangs. I notice similar case with sshd, ssh, ... as all these depend on prngd for random number. SMMEstack# /usr/sbin/sshd

Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 12:24:27 +0200 > > Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: > > On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller > > > > <smueller at chronox.de> wrote: > > > And finally, you have a coding error that is very very common but > > > fatal

Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 12:24:27 +0200 > > Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote: > > On Fri, Jul 29, 2016 at 7:40 AM, Stephan Mueller > > > > <smueller at chronox.de> wrote: > > > And finally, you have a coding error that is very very common but > > > fatal

Am Freitag, 29. Juli 2016, 10:14:07 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 15:12:30 +0200 > > Stephan Mueller <smueller at chronox.de> wrote as excerpted: > > Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: > > > In my opinion, assuming I am not doing something terribly wrong, > > > this constitutes a bug in the kernel's

Am Freitag, 29. Juli 2016, 10:14:07 CEST schrieb Alex Xu: Hi Alex, > On Fri, 29 Jul 2016 15:12:30 +0200 > > Stephan Mueller <smueller at chronox.de> wrote as excerpted: > > Am Freitag, 29. Juli 2016, 09:03:45 CEST schrieb Alex Xu: > > > In my opinion, assuming I am not doing something terribly wrong, > > > this constitutes a bug in the kernel's

Hello, I apologize if this is the wrong list. It was the list I was directed towards. I have reviewed the archives as well as everything I could google before posting. Any help is most appreciated: We're seeing an error during sftp and ssh connections with consistent regularity. It's triggered by a high number of connections coming into sftp/ssh at the same time. It affects

Hello When booting from a slow machine, I can observe dovecot blocking the whole boot process. I traced it down to the getrandom() system call in lib/randgen.c, which blocks until the random number generator is initialized (dmesg "random: crng init done"). This can take up to three minutes (!) on my machine, as there is not much entropy available (no hardware RNG, network VPN is also

> On 05 March 2019 at 18:51 William Taylor via dovecot <dovecot at dovecot.org> wrote: > > > On Tue, Mar 05, 2019 at 05:39:28PM +0100, Axel Burri via dovecot wrote: > > Hello > > > > When booting from a slow machine, I can observe dovecot blocking the > > whole boot process. I traced it down to the getrandom() system call in > > lib/randgen.c,

On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote: > > My understanding was that all three methods of obtaining entropy from > userspace all receive data from the CSPRNG in the kernel, and that the > only difference is that /dev/random and getrandom may block depending > on the kernel's estimate of the currently available entropy. This is incorrect. /dev/random is a

On Fri, Jul 29, 2016 at 01:31:14PM -0400, Alex Xu wrote: > > My understanding was that all three methods of obtaining entropy from > userspace all receive data from the CSPRNG in the kernel, and that the > only difference is that /dev/random and getrandom may block depending > on the kernel's estimate of the currently available entropy. This is incorrect. /dev/random is a

[NOTE: I'm new to this list and this is my first approach to OpenSSH code.] I've enhanced "--with-prngd-port=PORT" flag to accept an optional hostname as in "myhost:myport", e.g.: % ./configure --with-prngd-port=example.com:12345 Although I'm certain that this may cause big trouble if remote gatherer isn't online (ssh will refuse to open any connection) I

Now that ssh-rand-helper has been segregated into a separate program, I'd like to revisit an old question about its entropy gathering. - would it be desirable to make it possible for ssh-rand-helper to fall back to external commands if PRNGD cannot be reached, instead of choosing one or the other at compile time? - When using PRNGD, the program gets 48 bytes of entropy from PRNGD,

Linux 4.6, also tried 4.7, qemu 2.6, using this C program: #include <fcntl.h> #include <stdlib.h> #include <syscall.h> #include <unistd.h> int main(int argc, char *argv[]) { char buf[16]; int fd; if (argc != 2) return 1; for (int i = 0; i < atoi(argv[1]); i++) { sleep(1); if ((fd = open("/dev/random", O_RDONLY)) ==