sshd wont start automatically during startup

[Robert Duncan]

I cannot get sshd to start at boot time on 6.3.

I have the line to start it in /etc/rc.d/rc.local ( /opt/sbin/sshd -f
/etc/openssh/sshd_config )
There are other deamons in rc.local ( syslogd and smbd etc ) that start with
no problem
I can start sshd manually once the system is booted, and it works perfectly
There is nothing in /var/log/syslog ( no error, nothing!, and the config
file is set sshd has a log level of DEBUG )
There are no other log files that i can see that indicate any problem
There are no error messages during boot after 'Running extra services'
I had an almost identical setup with 6.2.1 that worked, only difference was
that sshd was in /usr/sbin

Any ideas why it wont start ??
Is there some other way to start things automatically ??

Regards,
Robert Duncan

PS. some system info:
QNX hostname 6.3.0 2004/04/29-21:23:19UTC x86pc x86
OpenSSH 3.7.1p1

[Mario Charest]

Does rc.local has +x bit set.

"Robert Duncan" <no-spam.rduncan@farleylaserlab.com.au> wrote in message
news:cbr2pu$l79$1@inn.qnx.com...

I cannot get sshd to start at boot time on 6.3.

I have the line to start it in /etc/rc.d/rc.local ( /opt/sbin/sshd -f
/etc/openssh/sshd_config )
There are other deamons in rc.local ( syslogd and smbd etc ) that start
with
no problem
I can start sshd manually once the system is booted, and it works
perfectly
There is nothing in /var/log/syslog ( no error, nothing!, and the config
file is set sshd has a log level of DEBUG )
There are no other log files that i can see that indicate any problem
There are no error messages during boot after 'Running extra services'
I had an almost identical setup with 6.2.1 that worked, only difference
was
that sshd was in /usr/sbin

Any ideas why it wont start ??
Is there some other way to start things automatically ??

Regards,
Robert Duncan

PS. some system info:
QNX hostname 6.3.0 2004/04/29-21:23:19UTC x86pc x86
OpenSSH 3.7.1p1

[Robert Duncan]

Yes, rc.local is executable. The strange things is that every other program
in it is being run.

in /opt/sbin
-rwxr-xr-x 1 root bin 258612 Sep 18 2003 sshd
-rwxr-xr-x 1 root bin 1416032 Jan 17 2003 smbd

in /etc/rc.d
-rwxrwxr-x 1 root root 175 Jun 29 15:44 rc.local

Also, i can put the line "/opt/sbin/sshd" in rc.local several times, and it
makes no difference, and there are still no error messages in
/var/log/syslog.

Q: is there some way of starting sshd from inetd, as i cannot get that to
work either.

Regards,
Robert Duncan


"Mario Charest" <nowheretobefound@8thdimension.com> wrote in message
news:cbrupm$e0o$1@inn.qnx.com...

Does rc.local has +x bit set.

[David Bacon]

That is very strange indeed. I also start sshd from my rc.local file. Here
are some long-shot suggestions for things to check:

- Are you sure the network is fully up (io-net has fully initialized and
created /dev/socket) by the time you start sshd?

- Are the environment variables the same in all significant ways when you
start it at the command line?

- Are you getting /opt/sbin/sshd as opposed to some other sshd when you
start it at the command line (OK, if the PATH is the same, you are )

dB

"Robert Duncan" <no-spam.rduncan@farleylaserlab.com.au> wrote in message
news:cbsn8u$25a$1@inn.qnx.com...

Yes, rc.local is executable. The strange things is that every other
program
in it is being run.

in /opt/sbin
-rwxr-xr-x 1 root bin 258612 Sep 18 2003 sshd
-rwxr-xr-x 1 root bin 1416032 Jan 17 2003 smbd

in /etc/rc.d
-rwxrwxr-x 1 root root 175 Jun 29 15:44 rc.local

Also, i can put the line "/opt/sbin/sshd" in rc.local several times, and
it
makes no difference, and there are still no error messages in
/var/log/syslog.

Q: is there some way of starting sshd from inetd, as i cannot get that to
work either.

Regards,
Robert Duncan


"Mario Charest" <nowheretobefound@8thdimension.com> wrote in message
news:cbrupm$e0o$1@inn.qnx.com...
Does rc.local has +x bit set.

[Robert Duncan]

New information:
During boot, after 'Starting extra run commands', i can see the line "PRNG
is not seeded" briefly before the login screen appears.

A quick search on the net and i found that this is due to a system not have
/dev/urandom /dev/random or the like.
I can see these files do exist, is it possible that the 'extra run commands'
in rc.local are being executed before /dev/random is created/initialized?

I still have the problem, so any ideas are appreciated.

Regards,
Robert Duncan

"Robert Duncan" <no-spam.rduncan@farleylaserlab.com.au> wrote in message
news:cbr2pu$l79$1@inn.qnx.com...

I cannot get sshd to start at boot time on 6.3.

I have the line to start it in /etc/rc.d/rc.local ( /opt/sbin/sshd -f
/etc/openssh/sshd_config )
There are other deamons in rc.local ( syslogd and smbd etc ) that start
with
no problem
I can start sshd manually once the system is booted, and it works
perfectly
There is nothing in /var/log/syslog ( no error, nothing!, and the config
file is set sshd has a log level of DEBUG )
There are no other log files that i can see that indicate any problem
There are no error messages during boot after 'Running extra services'
I had an almost identical setup with 6.2.1 that worked, only difference
was
that sshd was in /usr/sbin

Any ideas why it wont start ??
Is there some other way to start things automatically ??

Regards,
Robert Duncan

PS. some system info:
QNX hostname 6.3.0 2004/04/29-21:23:19UTC x86pc x86
OpenSSH 3.7.1p1

[DominiX]

ici même:cbt395$a9b$1@inn.qnx.com,
Robert Duncan <no-spam.rduncan@farleylaserlab.com.au> a écrit

New information:
During boot, after 'Starting extra run commands', i can see the line
"PRNG is not seeded" briefly before the login screen appears.

you need to setup /etc/prngd.conf
it is used to replace broken /dev/random

A quick search on the net and i found that this is due to a system
not have /dev/urandom /dev/random or the like.
I can see these files do exist, is it possible that the 'extra run
commands' in rc.local are being executed before /dev/random is
created/initialized?

I still have the problem, so any ideas are appreciated.

try to start sshd in rc.local with
"-ddd -e 2> /somewhere/sshd.failure.log"
and you may have some more verbose result

-- dominix

[cdm]

it is used to replace broken /dev/random

How is it broken?

chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

[Robert Duncan]

you need to setup /etc/prngd.conf
it is used to replace broken /dev/random

I dont actually have prngd, not that i can see. Nor did i have it in 6.2.1,
so any clues or resources on how to deal with prng and how to set up
/etc/prngd.conf would be nice.

Is PRNG packaged up inside something else other than OpenSSH, if so, what? I
can try re-install it.

Also, how do i tell if /dev/random is broken?

try to start sshd in rc.local with
"-ddd -e 2> /somewhere/sshd.failure.log"
and you may have some more verbose result

I did something similar, and just tried that exact one too, but there is
nothing other than the "PRNG is not seeded" line.

Thanks Again,
Robert Duncan

[DominiX]

ici même:cbt395$a9b$1@inn.qnx.com,
Robert Duncan <no-spam.rduncan@farleylaserlab.com.au> a écrit

New information:
During boot, after 'Starting extra run commands', i can see the line
"PRNG is not seeded" briefly before the login screen appears.

it could be a matter of openssl trouble
are you able to generate key ?
# ssh-keygen -d -f /tmp/foo -N ""

-- dominix

[pvbyl]

I have this same problem.

PRNG is not seeded. I posted a question in the 6.3 Beta group. Chris was
going to see if he could reproduce it.. Haven't heard anything yet...

I have also tried a wait for /dev/random and /dev/urandom but this doesn't
work.




"DominiX" <dominix@despamed.com> wrote in message
news:cc303c$s6i$1@inn.qnx.com...

ici même:cbt395$a9b$1@inn.qnx.com,
Robert Duncan <no-spam.rduncan@farleylaserlab.com.au> a écrit
New information:
During boot, after 'Starting extra run commands', i can see the line
"PRNG is not seeded" briefly before the login screen appears.

it could be a matter of openssl trouble
are you able to generate key ?
# ssh-keygen -d -f /tmp/foo -N ""

-- dominix

[Robert Duncan]

it could be a matter of openssl trouble
are you able to generate key ?
# ssh-keygen -d -f /tmp/foo -N ""

I am able to generate the keys using ssh-keygen, however, this is done
manually once the system is fully up and running. As mentioned before i am
also able to start sshd once the system is fully up too.

I tried adding a 'ssh-keygen' to /etc/rc.d/rc.local, and it also gave me the
"PRNG is not seeded" error while booting.

I am new to QNX, but to me it seems like whatever sshd needs in order to
start (openssl?), is not being loaded until after rc.local ...

[Robert Duncan]

I have this same problem.

PRNG is not seeded. I posted a question in the 6.3 Beta group. Chris was
going to see if he could reproduce it.. Haven't heard anything yet...

The steps i took in order to get this problem

1. Install 6.3 from cd
2. Install a couple of apps from 3rd party cd (OpenSSH, Samba, VIM) (OpenSSL
installed automatically as a dependancy)
3. Generate Keys: /etc/openssh/genhostkeys.sh
4. Create System Log: touch /var/log/syslog
5. Modify /etc/rc.d/rc.local to include the following

#!/bin/sh
/usr/sbin/syslogd
/opt/sbin/sshd
/usr/sbin/inetd

6. Reboot ...

During boot you see
...
Starting extra run commands
PRNG is not seeded


I have now tried this procedure with 6.3 PE and SE, both do the same.
I dont see how this is hardware related, but i will be trying on another box
when its ready.

[pvbyl]

I've done the same except for creating or running the syslog.


"Robert Duncan" <no-spam.rduncan@farleylaserlab.com.au> wrote in message
news:cca3a3$8on$1@inn.qnx.com...

I have this same problem.

PRNG is not seeded. I posted a question in the 6.3 Beta group. Chris
was
going to see if he could reproduce it.. Haven't heard anything yet...

The steps i took in order to get this problem

1. Install 6.3 from cd
2. Install a couple of apps from 3rd party cd (OpenSSH, Samba, VIM)
(OpenSSL
installed automatically as a dependancy)
3. Generate Keys: /etc/openssh/genhostkeys.sh
4. Create System Log: touch /var/log/syslog
5. Modify /etc/rc.d/rc.local to include the following

#!/bin/sh
/usr/sbin/syslogd
/opt/sbin/sshd
/usr/sbin/inetd

6. Reboot ...

During boot you see
..
Starting extra run commands
PRNG is not seeded


I have now tried this procedure with 6.3 PE and SE, both do the same.
I dont see how this is hardware related, but i will be trying on another
box
when its ready.

[David Bacon]

I don't know why the pseudo-random number generator (at least I
assume that's what PRNG stands for) has not yet "seeded" itself
by the time you try to start sshd in your /etc/rc.d/rc.local
file, but an easy workaround is just to put a "sleep" before the
/opt/sbin/sshd line.

The problem was easy to reproduce using QNX 6.3.0 under VMware,
so I also do not suspect a hardware problem. The only number of
seconds I've tried so far for the sleep is 5, which worked the
first time in this environment.

I hate to see sleeps in startup scripts - perhaps there is
something to which "waitfor" can be applied, but I don't know
what it would be (it ain't /dev/random, which already exists by
the time rc.local starts).

dB

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Paul Vander Byl" wrote ~ Mon, 5 Jul 2004 10:41:38 -0400:

I've done the same except for creating or running the syslog.


"Robert Duncan" <no-spam.rduncan@farleylaserlab.com.au> wrote in message
news:cca3a3$8on$1@inn.qnx.com...
I have this same problem.

PRNG is not seeded. I posted a question in the 6.3 Beta group. Chris
was
going to see if he could reproduce it.. Haven't heard anything yet...

The steps i took in order to get this problem

1. Install 6.3 from cd
2. Install a couple of apps from 3rd party cd (OpenSSH, Samba, VIM)
(OpenSSL
installed automatically as a dependancy)
3. Generate Keys: /etc/openssh/genhostkeys.sh
4. Create System Log: touch /var/log/syslog
5. Modify /etc/rc.d/rc.local to include the following

#!/bin/sh
/usr/sbin/syslogd
/opt/sbin/sshd
/usr/sbin/inetd

6. Reboot ...

During boot you see
..
Starting extra run commands
PRNG is not seeded


I have now tried this procedure with 6.3 PE and SE, both do the same.
I dont see how this is hardware related, but i will be trying on another
box
when its ready.

[pvbyl]

Works. sleep for 5 does the trick.


Thanks!



"David Bacon" <dbacon@qnx.com> wrote in message
news:1089046273430.dB@inn.qnx.com...

I don't know why the pseudo-random number generator (at least I
assume that's what PRNG stands for) has not yet "seeded" itself
by the time you try to start sshd in your /etc/rc.d/rc.local
file, but an easy workaround is just to put a "sleep" before the
/opt/sbin/sshd line.

The problem was easy to reproduce using QNX 6.3.0 under VMware,
so I also do not suspect a hardware problem. The only number of
seconds I've tried so far for the sleep is 5, which worked the
first time in this environment.

I hate to see sleeps in startup scripts - perhaps there is
something to which "waitfor" can be applied, but I don't know
what it would be (it ain't /dev/random, which already exists by
the time rc.local starts).

dB

- - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Paul Vander Byl" wrote ~ Mon, 5 Jul 2004 10:41:38 -0400:
I've done the same except for creating or running the syslog.


"Robert Duncan" <no-spam.rduncan@farleylaserlab.com.au> wrote in message
news:cca3a3$8on$1@inn.qnx.com...
I have this same problem.

PRNG is not seeded. I posted a question in the 6.3 Beta group.
Chris
was
going to see if he could reproduce it.. Haven't heard anything
yet...

The steps i took in order to get this problem

1. Install 6.3 from cd
2. Install a couple of apps from 3rd party cd (OpenSSH, Samba, VIM)
(OpenSSL
installed automatically as a dependancy)
3. Generate Keys: /etc/openssh/genhostkeys.sh
4. Create System Log: touch /var/log/syslog
5. Modify /etc/rc.d/rc.local to include the following

#!/bin/sh
/usr/sbin/syslogd
/opt/sbin/sshd
/usr/sbin/inetd

6. Reboot ...

During boot you see
..
Starting extra run commands
PRNG is not seeded


I have now tried this procedure with 6.3 PE and SE, both do the same.
I dont see how this is hardware related, but i will be trying on
another
box
when its ready.