Re: SSH as root

From: Michael Coulter (mjc_at_bitz.ca)
Date: 07/06/03

  • Next message: Michael Coulter: "Re: SSH as root"
    Date: Sat, 5 Jul 2003 18:38:24 -0700
    To: Tim Greer <chatmaster@charter.net>
    
    

    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 ?
     
    > > 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 :)

    Hopefully you can understand my concern with having to throwaway root passwords
    every time a machine you have credentials on is compromised. With keys, the
    people's who machines I admin can get rooted all they want and it's not
    a threat to my credentials.
     
    > 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.

    > 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.
    I don't know anyone who enjoys trying to store 200 unique, secure,
    passwords, but that seems to be what you prefer.
     
    > > 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.

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

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


  • Next message: Michael Coulter: "Re: SSH as root"

    Relevant Pages

    • Re: request for comments : slush
      ... You then connect back out via SSH client, ... web client or mail client on that server? ... has your passwords, and uses the same password you used for one to break ... that full session encryption is an unacceptable load, ...
      (comp.security.ssh)
    • Re: Novell/Windows 2003 PW Syncing problem
      ... Every 45 days, Netware forces the users to change passwords which undoes the sync between our windows clients and the server, so our UNC drive mappings no longer work. ... In fact the novell client changes the windows passwords automatically in order to make windows login automatic. ...
      (comp.os.netware.misc)
    • Re: ssh security question
      ... In my case - the client is a windows client and the ssh is embedded into the windows nx client. ... Is there any reason I can't run ssh-keygen on the server and copy the private key to the client - and the public key to the "authorised" directory? ... sniffer can catch your passwords, and it would make it trivial to log in ...
      (SSH)
    • Re: Cant change security policy
      ... I'll try to get the secure passwords accepted by the client, ... While the server was just server and no ... > improved security policy that will go into effect 7 days after the system is ...
      (microsoft.public.windows.server.sbs)
    • Re: SSH as root
      ... Server A to Server B, that if Server A was compromised, they now own Server ... see how passwords are less secure in anyone's mind, ... >> Passwords are inferior to keys in at least 3 regards: ... > unix passwords is when the same passwordcan be used to compromise ...
      (SSH)