Problems with Sudo

[Arthur H. Johnson II]

On Thu, 2007-03-15 at 17:19 -0400, Jeffrey F. Bloss wrote:
> Arthur H. Johnson II wrote:
> 
> > As far as "why" its a personal security policy I've used since the
> > beginning.  An alternate SSH server operating on an alternate port,
> > where only one unprivileged account is allowed to log in.  From there,
> > su to switch to real user. 
> 
> But 'su' is not what you're doing, and that may have something
> to do with your problem. Could be as trivial as confusing passwords
> while trying to keep SSH/su "target user password" requirements
> separated from sudo's "caller password" requirement in your head while
> account hopping. ;)
> 

No, I'm entering the right password for the "localuser".

Actually, su is out of the equation.  See below.

> In any case, you're gaining nothing at all by running two ssh daemons
> and connecting one to another this way. It's equally secure and less
> resource intense to simply restrict ssh logins to an unprivileged
> account and su to an "admin" account as needed. It's not even
> significantly less secure to allow SSH to an "admin" account as long as
> you implement good authentication practices.

The alternate SSH server is actually this special one:

http://chrootssh.sf.net

When the "remoteuser" logs in, they are placed in a chrooted
environment.  Nothing useful in the env, except SSH which allows me to
ssh to something else on the network, namely the localhost interface or
one of my other machines.  The problem with sudo still persists after I
ssh to the local host's localuser.

At any rate, nobody has really answered my question, instead they want
me to change my personal security policy.  Thats fine, I just want to
know why sudo is acting in a bizzare, and possibly messed up way.

Perhaps this list can't answer my question, in which case, I'll move on
to a sudo mailing list or forum.  Its possible this is a privilege
escalation feature not found in my Debian box.  

-- 
Arthur H. Johnson II <arthur at johnsonfamilymi.us>