SSH RSA Command Key with Forking Proc not Working?

[Ralph Grothe]

Good Friday Folks,

I think this issue of mine has already been raised here?
Anyway hoping this case won't be too much of a deja vue to the discerning reader.

I wish to define a nagios event handler for a flaky Entropy Gathering Daemon (egd) on an old AIX iron, which is so much outdated that it lacks contemporary /dev/[u]?random devices for seeding crypto key generating apps like sshd.

Currently my nagios service check_procs of this occassionally dying egd kludge only would send email notifications to admins if after 5 retry checks this service's hard state would still remain critical, who then would need to login on the box and start the egd Perl script manually as root.

This rather lends itself to be done automatically by nagios by an event handler.

As the egd needs to be started as root
and nagios event handler only runs with restricted privileges one would have to set up some sudo command on the AIX box.
But sudo isn't installed there and I'm not the admin in charge of this host to be eligible to install additional software there.

So I thought an SSH RSA command key for the root account would be the ideal solution.

Thus I generated an RSA key for the nagios user on the nagios server with a command string as can be seen from below verbose execution and appended it to root's authorized_keys2 (as you can see, even sshd is pretty dated there!) on the monitored egd host.

When I kill the egd on the monitored host and execute my ssh rsa command key the egd won't be started.

on egd host:

# ps -e -o pid= -o args=|awk '!/awk/&&/egd/'
107746 perl -w /usr/local/bin/egd.pl /dev/entropy

# kill 107746

# ps -e -o pid= -o args=|awk '!/awk/&&/egd/'


as nagios on nagios server:

$ ssh -v -i ~/.ssh/id_rsa_aixbox_egd_start -l root dagobert 2>&1|grep -E emote:\|exit
debug1: Remote: Forced command: if ps -e -o args=|awk '/egd\.pl/{exit 1}';then cd /;/usr/l
ocal/bin/egd.pl /dev/entropy;fi >/tmp/egd_rsa_start.log 2>&1
debug1: Remote: Pty allocation disabled.
debug1: Remote: Port forwarding disabled.
debug1: Remote: X11 forwarding disabled.
debug1: Remote: Agent forwarding disabled.
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0


However, when I execute the command on the egd host the daemon gets started:

# ps -e -o pid= -o args=|awk '!/awk/&&/egd/'
# ls -l /tmp/egd_rsa_start.log
-rw-r--r-- 1 root system 0 Feb 16 12:43 /tmp/egd_rsa_start.log
# if ps -e -o args=|awk '/egd\.pl/{exit 1}';then cd /;/usr/local/bin/egd.pl /dev/entropy;fi
25 sources found
forking into background...
server starting
# ps -e -o pid= -o args=|awk '!/awk/&&/egd/'
85284 perl -w /usr/local/bin/egd.pl /dev/entropy


My suspicion is, that this may be owe to that the egd.pl daemon is poorly written as far as proper dissociation and backgrounding is concerned (viz. no closing of all i/o channels, no changing dir to /, no becoming of session leader etc.)

I found this block in egd.pl' s code where the forking and exiting of the parent is taking place, and where the author even admids the deficiencies of their daemon in the comments.

Could this be the cause why my ssh rsa command isn't working?



396 # ok, now put ourselves in the background if that's what we're going to do
397 unless ($nofork) {
398 # things we ought to do (according to perlipc):
399 # open /dev/tty and TIOCNOTTY it
400 # chdir("/");
401 # reopen stdin,out,err so they're not connected to the old tty
402 # background ourselves
403
404 print STDERR "forking into background...\n";
405
406 # for now, just do the last one. I'd like some error/debug messages to
407 # have somewhere to go for a while, and the sockets might be relative
408 # to the current directory.
409 fork && exit(0);
410 }

[Steven E. Protter]

Shalom,

I'm with you on your suspicions.

I suggest a tusc trace on the process. Perhaps tcpdump might help if there is a network handshake,connect issue.

Access to the other boxes syslog might be helpful.

SEP

[Ralph Grothe]

Hello Steven,

I had a look at the sshd_config file to find out what kind of logging (if any) was enabled.
Luckily, it defaulted to facility auth and and loglevel info (so I didn't need to change sshd_config).
From syslog.conf I could see that sshd's log messages went to /var/adm/syslog.

A short glance at it told me that this was the classic hen egg paradox.
To have any RSA command key run the sshd needed to gather sufficient entropy for creation of session keys from the very /dev/entropy device a snuffed egd couldn't provide anymore.

# grep entropy /var/adm/syslog|tail -1
Feb 19 10:57:15 dagobert opensshd[5422]: error: Couldn't connect to EGD socket "
/dev/entropy": Connection refused


I was really wondering where the sshd was told to use /dev/entropy because I couldn't find any references in the sshd_config file.
But grepping for the device in the sshd binary output this, so that I assume that my admin colleague in charge of this host must have built the sshd from sources with a configure option that told sshd to use that unix domain socket by any means.

# strings /usr/local/bin/opensshd|grep /dev/entropy
|/dev/entropy
/dev/entropy
/dev/entropy


Seems that RSA command keys obviously aren't an option.
What remains would either be installing sudo,
or write an egd event handler that would be owned by root, suid bit set, and executed through the nrpe (nagios remote plug-in executor), which already was installed by me on this host and which is an inetd started service.

The latter I have done but now struggle with another problem.

When I kill the egd, and run my egd event handler by check_nrpe from my nagios server,
in the logfile of my event handler on the egd host I get this output:

# cat /tmp/egd_rsa_start.log
25 sources found
forking into background...
server starting
can't create socket /dev/entropy : A file descriptor does not refer to an open file. at /usr/local/bin/egd.pl line 582.


In line 582 of the egd there's a die
if the creation of the unix domain socket fails.
I wonder if "patching" the egd code
by adding e.g. a SO_REUSEADDR option?
But I doubt since unix sockets unlike inet sockets are merely local files (therefore the above mentioned dangling file descriptor during open attempt), and probably the reuse socket option isn't applicable to unix sockets?

Could you advise me how to get a valid file descriptor in this surrounding?

# cat -n /usr/local/bin/egd.pl|sed -n 573,583p
573 } else {
574 print STDERR "listening on unix socket at $where\n" if $debug_cl
ient;
575 unlink($where);
576 $s = new IO::Socket::UNIX (
577 'Type' => SOCK_STREAM,
578 'Local' => $where,
579 'Listen' => 1,
580 );
581 }
582 die "can't create socket $where : $!" unless $s;
583 $s->listen or die("couldn't listen on socket $where : $!");