error: rexec of /usr/sbin/extsshd failed: Permission denied

[Dale Dellutri]

I have a separate instance of sshd running which I've renamed
extsshd. extsshd has its own config and key files so that
I can maintain a separate policy for connections from the
external world. sshd does connections from inside the lan.

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 <ddelQ...@panQQQix.com> (lose the Q's)

[Shai Ayal]

I'm not sure as to the source of the error, but if your file system supports it, maybe a hard link would do the trick

Shai

[Dale Dellutri]

On 05 May 2012 23:05:27 GMT, all mail refused <elvis...@notatla.org.uk> wrote:
> > Part of the setup requires creating a symbolic link to the original
> > sshd program:

> Why not keep only one program file but have one process use -C
> to a different sshd_config?

This is from my web site info
http://www.DaleDellutri.com -> Programming

"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 <ddel...@panix.com>