This kind of setup has worked on previous servers very well.

Part of the setup requires creating a symbolic link to the original
sshd program:
  # ls -lZ /usr/sbin/*ssh*
  lrwxrwxrwx. root root system_u:object_r:sshd_exec_t:s0 /usr/sbin/extsshd -> sshd
  -rwxr-xr-x. root root system_u:object_r:sshd_exec_t:s0 /usr/sbin/sshd
I use a symbolic link instead of copying the binary so that
when ssh is updated, I don't have to re-copy the program.

However, I'm now getting this in the /var/log/secure:
  error: rexec of /usr/sbin/extsshd failed: Permission denied

Why is ssh trying to rexec the executable?
Why should it get "Permission denied" given that it's just a link?
Where can I look to try to trace down the cause of this error?

I do NOT get this error if I remove the symbolic link and
simply copy the executable:
  # cd /usr/sbin
  # cp -iva sshd extsshd
But then I'd have to remember to re-copy the executable each
time an update to ssh occurs.

--
Dale Dellutri <ddelQQQl...@panQQQix.com> (lose the Q's)

Shai

"I've been asked why I needed to make a new init file and a new soft
link to the executable. There are three reasons. First, some of the
subroutines in the init script depend on the executable name being the
same as the service name. Second, when I do a "ps" or something else
that shows statistics by process, I'd be able to tell which ssh daemon
is which. Third, having a new name gives a consistent naming scheme to
all components of the new (RedHat-style) service."

By the way, I'm still getting the error message, but it doesn't seem
to make any difference.  It works even with the error message.

--
Dale Dellutri <ddell...@panix.com>