>>>>> "James" == James Ponder <jamessquish.net> writes:

    James> Now, you want to do some maintenance one day:

    James> * If you connect to this machine via ssh and run
    James> '/usr/bin/su' you lose your root password to the attacker.

true

    James> * If you connect to this machine via ssh and run sudo, you
    James> lose your user account password to the attacker.

true

    James> * If you had logged in as root via ssh, you wouldn't have
    James> lost any access details.

true

    James> As pointed out to me, there are mechanisms such as s/key
    James> that could be used, but that is a real effort to most
    James> people. Plus, you could have many different root
    James> passwords, but again, that is a real effort to most people
    James> too.

    James> So, in this situation, wouldn't ssh to root be better?

Yes, but there are better alternatives still. challenge/response tokens
are not that hard to come by. If you have a PDA of any kind you can easily
set it up to generate your s/key (or other otp authentication) response.

Another idea I have not tested but ought to work is to have several
root accounts, i.e. different names but with uid zero. All these have
their own home dirs with their own .ssh/authorized_keys. That way
every admin can have their own account, so accountability of the
session is not lost (of course file ownership will only show root, but
that is the same with sudo et al.). You can also setup an extra
account with a key-pair you deposit somewhere, in order to not lose
administration possibility should all the admins disappear.

or just use kerberos authentication for SSH...

Niklas

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]