OpenSSH does not build on QNX 6.3.0: configure doesn't recognize the system as a QNX Neutrino system; it tries to use lastlog.h, which isn't available; and it tries to use /etc/default/login, which has an incompatible format. I'll attach a patch that fixes the first two problems. I wasn't sure how to fix the third, so I worked around it by passing --disable-etc-default-login to configure.
Created attachment 1060 [details] Patch
(In reply to comment #0) > OpenSSH does not build on QNX 6.3.0: configure doesn't recognize the system as > a QNX Neutrino system; it tries to use lastlog.h, which isn't available; and it > tries to use /etc/default/login, which has an incompatible format. What is the output of config.guess on QNX? The configure script is broken on 4.3p1. Please apply the patch sent to the list ad report back. http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=113892892008957 or http://www.zip.com.au/~dtucker/openssh/4.3p1-configure.patch
(In reply to comment #2) > (In reply to comment #0) > > OpenSSH does not build on QNX 6.3.0: configure doesn't recognize the system as > > a QNX Neutrino system; it tries to use lastlog.h, which isn't available; and it > > tries to use /etc/default/login, which has an incompatible format. > > What is the output of config.guess on QNX? i386-pc-nto-qnx6.3.0 > The configure script is broken on 4.3p1. Please apply the patch sent to the > list ad report back. > > http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=113892892008957 > or > http://www.zip.com.au/~dtucker/openssh/4.3p1-configure.patch I still needed the patch I attached to compile.
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #0) > > > OpenSSH does not build on QNX 6.3.0: configure doesn't recognize the system as > > > a QNX Neutrino system; it tries to use lastlog.h, which isn't available; and it > > > tries to use /etc/default/login, which has an incompatible format. > > > > What is the output of config.guess on QNX? > > i386-pc-nto-qnx6.3.0 > OK this part is a no brainer. -*-*-nto-qnx) +*-*-nto-qnx*) Is defining DISABLE_LASTLOG correct for ALL nto-qnx versions?
(In reply to comment #4) > Is defining DISABLE_LASTLOG correct for ALL nto-qnx versions? I don't know: I only have access to QNX 6.3.0 systems. I doubt that QNX would have removed support for it, though.
(In reply to comment #5) > (In reply to comment #4) > > Is defining DISABLE_LASTLOG correct for ALL nto-qnx versions? > > I don't know: I only have access to QNX 6.3.0 systems. I doubt that QNX would > have removed support for it, though. > Probably not. OK. fix commited. Please test the next snapshot.
(In reply to comment #6) > Probably not. OK. fix commited. Please test the next snapshot. The 20060206 snapshot built successfully but the resulting binaries still tried to use /etc/default/login.
Created attachment 1062 [details] disable /etc/default/logn check on qnx Sorry, forgot abour your /etc/default/login issue. I guess you'd rather not "configure --disable-etc-default-login" Try this patch to confiugure.ac
(In reply to comment #8) > Created an attachment (id=1062) [edit] > disable /etc/default/logn check on qnx > > Sorry, forgot abour your /etc/default/login issue. > I guess you'd rather not "configure --disable-etc-default-login" > Try this patch to confiugure.ac That didn't seem to work. It looks like it was reset to yes on line 25979 of configure.
(In reply to comment #9) > > That didn't seem to work. It looks like it was reset to yes on line 25979 of > configure. > Ahh, that should have been enable_etc_default_login=no
(In reply to comment #10) > Ahh, that should have been > enable_etc_default_login=no Substituting enable_etc_default_login for etc_default_login in the patch fixes the problem.
When I start sshd during the boot process, it prints the following message and exits: > PRNG is not seeded Here's the relevant excerpt from config.log: > configure:15440: checking whether OpenSSL's PRNG is internally seeded > configure:15465: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lcrypto -lz -lsocket >&5 > configure:15468: $? = 0 > configure:15470: ./conftest > configure:15473: $? = 0 > configure:15477: result: yes Adding with_rand_helper=yes to the nto-qnx case fixes this problem.
(In reply to comment #12) > When I start sshd during the boot process, it prints the following message and > exits: > > > PRNG is not seeded > > Here's the relevant excerpt from config.log: > > > configure:15440: checking whether OpenSSL's PRNG is internally seeded > > configure:15465: gcc -o conftest -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -I/usr/local/ssl/include -L/usr/local/ssl/lib conftest.c -lcrypto -lz -lsocket >&5 > > configure:15468: $? = 0 > > configure:15470: ./conftest > > configure:15473: $? = 0 > > configure:15477: result: yes > If your OpenSSL is internally seeded but you are seeing "PRNG is not seeded" on boot, I can only guess that there is not enough random data on boot. What is the source of random data on QNX? If you are running prngd, is it starting well before sshd? > Adding > > with_rand_helper=yes > to the nto-qnx case fixes this problem. That will not be going into configure.ac.
(In reply to comment #13) > > Adding with_rand_helper=yes > > to the nto-qnx case fixes this problem. > > That will not be going into configure.ac. Yeah, it's a host-specific thing not a platform-specific thing. Configure does the right thing for the configuration it's running on, but if you have a host that might or might not need it (or are packaging for multiple hosts with differing configurations), it can be forcibly enabled at configure time with the --with-rand-helper option.
I've commited the patch to disable /etc/default/login checks on QNX Closing bug
(In reply to comment #13) > If your OpenSSL is internally seeded but you are seeing "PRNG is not seeded" > on boot, I can only guess that there is not enough random data on boot. > What is the source of random data on QNX? There is a program named random that can collect data from interrupts, /proc, and the high-performance clock. Would it be possible to make sshd wait for enough entropy to be collected instead of exiting?
(In reply to comment #16) > There is a program named random that can collect data from interrupts, /proc, > and the high-performance clock. Would it be possible to make sshd wait for > enough entropy to be collected instead of exiting? You could modify entropy.c, but having sshd potentially hang on startup is probably not a good idea in general. You could also have the startup script wait (trivial program with RAND_status()/sleep(1) in a loop). Most other platforms solve this kind of problem by saving the random seed on shutdown and reseeding on startup.
(In reply to comment #17) > Most other platforms solve this kind of problem by saving the random seed on > shutdown and reseeding on startup. Does sshd do this or does some other operating system service? If I were to write my own program to do so, would I use RAND_file_name, RAND_write_file, and RAND_read_file or should I seed the operating system's random number generator (assuming the RAND functions don't do so)?
(In reply to comment #18) > (In reply to comment #17) > > Most other platforms solve this kind of problem by saving the random seed on > > shutdown and reseeding on startup. > > Does sshd do this or does some other operating system service? It's usually either the entropy collector service itself when shut down (eg prngd) or the system shutdown scripts (eg most Linuxes will do something like "dd if=/dev/urandom of=/some/file bs=512 count=1"). > If I were to > write my own program to do so, would I use RAND_file_name, RAND_write_file, > and RAND_read_file or should I seed the operating system's random number > generator (assuming the RAND functions don't do so)? For best effect should to use the OS's facilities since that would help all users of the entropy source, but for users of OpenSSL (including OpenSSH) the RAND_* functions mentioned above seem as if they would be adequate (although I've not used them). Whatever you do you should try not to reuse the same seedfile.
Change all RESOLVED bug to CLOSED with the exception of the ones fixed post-4.4.