Problems with Sudo

[Jeffrey F. Bloss]

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. ;)

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.

In fact, having multiple accounts properly set up is even more secure
than a single account in some ways due to the "all your eggs in one
basket" principle. If you only have one way in and it gets cracked,
everything is lost. The second SSH is utterly useless. Certainly no
more useful than a simple 'su localuser', and the extra daemon instance
is another point of failure. If you keep user and admin logins
segregated a compromise of the "user" account can be dealt with.

Using odd port numbers isn't very useful either, but it doesn't hurt.
Not much anyway, although it may at some point get you a little more
attention if some script kiddie decides SSH on a nonstandard port is
more "interesting". ;) You're way further ahead of the game to simply
use strong passwords, or better yet no password access at all, and port
knock or rate limit failed login attempts to keep people from hammering
on your port. This way you also avoid being locked out from locations
that might restrict whatever nonstandard port you choose.

I have SSH exposed to the world with key-only login and an iptables
ruleset that that drops new connections from external IP addresses for
several minutes if it sees a failed login attempt. I get poked at
*maybe* once or twice a month, as opposed to the 200 to 300 per day
brute force attempts I was getting before the rate limiting. Evidence
that the script kiddies trade information. ;) Of course disallowing
password authentication all together makes even those infrequent probes
irrelevant.

FWIW, I also keep my private keys on a small truecrypt container (on my
laptop) so even if it's lost or stolen I have no worries. Unless
someone cracks my insanely long, random, truecrypt password that is. I
consider that setup... key-only login with root disallowed and secured
keys... about as secure as you can get within reason.


> > I still don't get why you don't just connect as 'localuser'
> 
> Again, security policy.  I don't want to expose the "localuser"
> account to the internet.

Using su and sudo are the accepted ways to move between accounts
without exposing them to outside access. There's no advantage, and
potential for more breakage, by doing the "double SSH" thing you're
doing.

-- 
     _?_      Outside of a dog, a book is a man's best friend.
    (o o)         Inside of a dog, it's too dark to read.
-oOO-(_)--OOo------------------------------[ Groucho Marx ]---
                    http://wrench.homelinux.net/~jeff/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 892 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/ubuntu-users/attachments/20070315/a9fd19cf/attachment.sig>