Re: SSH as root

From: Tim Greer (chatmaster_at_charter.net)
Date: 07/06/03

  • Next message: Kevin Calman: "Re: Keychain problems"
    To: "Michael Coulter" <mjc@bitz.ca>
    Date: Sat, 5 Jul 2003 19:11:25 -0700
    
    

    ----- Original Message -----
    From: "Michael Coulter" <mjc@bitz.ca>
    To: "Tim Greer" <chatmaster@charter.net>
    Cc: "Paul Bauer" <paul@shorttermwhat.com>; <secureshell@securityfocus.com>
    Sent: Saturday, July 05, 2003 6:38 PM
    Subject: Re: SSH as root

    > On Sat, Jul 05, 2003 at 02:03:38PM -0700, Tim Greer wrote:
    >
    >
    > > I'm not denying that people don't practice the best methods and that is
    a
    > > potential issue, but for people smart enough not to do it, it's a non
    issue.
    >
    > Not to do what ?

    Use the same root password on all their servers, didn't you read what I
    said? Why don't you just read what I said, instead of asking me to repeat
    it?

    > > > Most cases I've seen where people do this, there's a pile of sticky
    notes
    > > > somewhere with a lot of root passwords.
    > >
    > > Right, but if someone's going to break into your office or home to get
    the
    > > passwords, they could just steal/take the system itself or they will
    have
    > > physical access.
    >
    > Or a sales person could take a customer for an office tour. This is whole
    > different can of worms though :)

    Yes, that's true. But, who's have them in plain site?

    > Hopefully you can understand my concern with having to throwaway root
    passwords
    > every time a machine you have credentials on is compromised.

    I can, and I'm not meaning to say you are stupid for using the same root
    pass for all your servers, I just have a different view. I'm not trying to
    insult you by saying it. It's just better to have people require two steps
    to log in. They can still be forced or asked to use keys with pass phrases,
    etc. if you want, that's not a bad idea, but then to have to su to root.
    This is safer due to the extra step involved to compromise the system via
    logins and also for the sake of preventing major mistakes by staff members.
    The different passwords on different servers is good for that reason, in
    case someone's running a sniffer on a now compromised system. You're right
    that direct root login will prevent them from getting the passwords if you
    use keys and yes, that would help, especially if you use the same root
    password. So, I suppose just make sure no one can su to root or have to use
    the password on the system at any time, and don't ever connect out to
    another server from that system.

    > With keys, the
    > people's who machines I admin can get rooted all they want and it's not
    > a threat to my credentials.

    Okay.

    > > Passwords wouldn't be on the server, in a perfect world, or system.
    Right,
    >
    > In the real world, private keys are not on the server. They are on the
    client,
    > which must be protected in any authentication model.

    Or so they should be, but I've seen about 20% of server owners/clients use
    trust relationships.

    > > Yes, in regards to using the same password on another system, service,
    etc.
    > > Hey, I'm not opposed to protecting it anyway, but if the server I'm
    > > connecting to is compromised, I'm sure not going to be using the same
    > > password anyway... and, I say once again, I did claim this would be a
    better
    > > method if you used the same password for other servers. I never would,
    and
    > > this is why there's not really any advantage in my opinion.
    >
    > Ok, say you're managing about 200 linux boxes of various customers, that
    > you have root on, but are not 100% responsible for. With keys, you don't
    > even need to bother to generate a new random password when any of those
    > machines is compromised. It at least simplifies your password management.

    Yes, it would be simpler, I suppose, but it's just as easy to change the
    root password on a compromised system, which is a good idea, even if you use
    keys. After all, strong passwords are still a good thing and they could be
    cracked otherwise... even if it takes a few months.

    > I don't know anyone who enjoys trying to store 200 unique, secure,
    > passwords, but that seems to be what you prefer.

    Yes, it is, I make sure none of my clients, by my choice nor theirs, use the
    same root password as another client's server. I can't belueve you'd
    suggest your clients use the same root password(s), to make it easier on
    you.

    > > > Can you guarantee that all of the users on these systems also have
    unique
    > > > passwords for every service on every machine ?
    > >
    > > I can, yes.
    >
    > You're very lucky then. I highly doubt this is typical.

    Why am I lucky? I don't force clients to use the same root password as
    other clients. They all have either strong passwords generated per
    system/client, or they choose their own. I highly doubt the suggestion of
    yours to have them use the same root passs is "typical". I mean, you
    mentioned 200 client servers, why would you assign them the same root
    password?

    > > > Keys ALWAYS require information NOT on the server.
    > >
    > > They don't "always", it depends on how you set them up.
    >
    > Are you talking about keys with passphrase vs. ones without here ?
    > I couldn't find any facts regarding this statement.

    Maybe you can read my other emails, and this one too, since you keep asking
    me things I've already said. For that matter, I've clearly said it above,
    which now apparently still requires ti to be substanciated? What is the
    point to this? I've been more than clear by now and apologized if I wasn't
    previously. What do you expect me to do for this to end?

    > The only time that statement is in the ballpark of truth, is if you are
    storing
    > your private key on the server with no passphrase on it.

    I stated, clearly, and above, is that people that create trust
    relationships. Nothing more, nothing less. I don't see where the confusion
    is, since I've very clearly said this in the last few emails, the one you
    just replied to and now my reply to it. We have no need to continue
    discussing it. We can disagree about assigning passwords and how they are
    remembered or stored, etc. Albeit, I can't imagine assigning the same root
    pass (or pass phrase) to different clients. I also can't imagine people
    would implement a security policy, only to have them written down on post-it
    notes, while allowing people to take a tour of that area, those terminals,
    etc. to get near them, have them in plain sight and not closely monitor the
    people you are giving a tour of where you store your post-it notes at. I
    guess we can disagree about that, too.

    > There is no possible
    > reason to do it unless you are using it as a client as well. Then it
    should
    > be referred to as a client machine, because that's where the problem
    arises.

    Yes, a client system, or a work station or a server, anywhere that would for
    some reason use keys that are for the purpose of a trust relationship, that
    would allow anyone with access (locally or remotely) to use that now
    compromised system's shell (for example) or SSH program, to log in without
    the need for supplying any type of information... of course, that's not what
    you were talking about, right? So, why are we still discussing this, since
    I've once again responded with yet another confirmation that "yes, I say
    again, that is what I meant". Oh well.

    --
    Regards,
    Tim Greer  chatmaster@charter.net
    Server administration, security, programming, consulting.
    

  • Next message: Kevin Calman: "Re: Keychain problems"

    Relevant Pages

    • [Full-Disclosure] RFX Networks
      ... | in security and scalable server management on varying levels. ... | monitor to take action during situations of service failure. ... Got Root? ... Your Server login ID is: ...
      (Full-Disclosure)
    • Re: SSH as root
      ... Subject: SSH as root ... That's too bad, I mean, that keys are a benefit from poor choices (i.e., ... On the server side, no. ... If someone compromises a system, every single thing other than the passwords ...
      (SSH)
    • RFX Networks/ RackAdmin.com ALERT
      ... below was posted to some security websites. ... | in security and scalable server management on varying levels. ... Got Root? ... Your Server login ID is: ...
      (comp.os.linux)
    • RFX NETWORKS ALERT
      ... below was posted to some security websites. ... | in security and scalable server management on varying levels. ... Got Root? ... Your Server login ID is: ...
      (alt.linux)
    • Solaris Sparc 9 12/3 Core ./installer failing due Java?
      ... system SUNWadmr System & Network Administration Root ... system SUNWapchd Apache Web Server Documentation ... system SUNWapchu Apache Web Server (usr) ... system SUNWaudd Audio Drivers ...
      (comp.unix.solaris)