[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposed: task-secure-system package



>>>>> "Russell" == Russell Coker <russell@coker.com.au> writes:

    >>> >permissions, disallow remote-root ssh logins etc.).
    >>> 
    >>> I disagree.  I think that in the way machines get used in
    >>> large networks allowing remote root logins via RSA key is
    >>> good.
    >> disagree ;) It's offtopic here i guess, but i think there's
    >> never a need to remote-login as root. There's always the
    >> 'operator' account (in case of nis), or some other local
    >> account (non-nis), and in the worst-case scenario of
    >> no-user-accounts-working-anymore there's the console.

    Russell> No.  I like to have ssh as root enabled so that I can
    Russell> login directly to do regular maintenance tasks with
    Russell> minimum stuffing around.  Doing the "enter password to su
    Russell> to root" thing works if you run one or two machines.  But
    Russell> if you run 50 machines it's ridiculous to consider such
    Russell> things.

I happen to agree with Russell here. Or, rather, it is a compromise
between two risks:

a) that after entering your password each time, for 50 machines,
somebody happens to observe it being entered on the 26th time, and can
re-enter it; or you write the password down (how do you remember 50
different passwords otherwise?). If the password is stolen (eg.
remote system is compromised), it is much more serious if you use the
same password for every system.

b) that your private key gets stolen AND a dictionary attack reveals
your password. (As, using ssh-agent, you only need to enter the
password once, the points in (a) do not apply).

c) Kerberos, my preference, even though I do not know if any
implementation exists with Pk-Cross (public key extensions): that your
ticket gets stolen anywhere up to before the expiry time.

More paranoia:

a) entering you password via an untrusted computer. Same goes with
storing a private key on an untrusted system, but I would hope nobody
would do that...

b+c) problem here is that some
trojan-horse-disguised-as-netscape-version-7 could automatically
invoke "ssh -lroot remote.system rm -rf /", but I think this might be
getting a bit paranoid. I wonder if you would be able to use
capabilities to limit these privileges (whether ssh-agent or Kerberos
ticket) to designated processes?

c) accessing a remote system via an untrusted system is only a problem
up to the expiry time on the Kerberos ticket... Just as long as you trust
the initial kinit process with your password.

I think that is a mostly unbiased representation...
-- 
Brian May <bam@debian.org>



Reply to: