Re: SSH as root

• Previous message: Arthur: "Fw: how to use both key and password authentication to sshd ?"
• Maybe in reply to: Paul Bauer: "SSH as root"
• Next in thread: Michael Coulter: "Re: SSH as root"
• Reply: Michael Coulter: "Re: SSH as root"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

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.

• Previous message: Arthur: "Fw: how to use both key and password authentication to sshd ?"
• Maybe in reply to: Paul Bauer: "SSH as root"
• Next in thread: Michael Coulter: "Re: SSH as root"
• Reply: Michael Coulter: "Re: SSH as root"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]