[lug] root password

[Nate Duehr]

Rob Nagler wrote:
> Sean Reifschneider writes:
>> These days, we also recommend that SSH password authentication be disabled,
>> because of the number of scans going on looking for weak passwords, and the
>> rate of escalation of those scans.
> 
> I have always wondered about this.  It seems to me that you can't
> crack passwords through the sshd; it's computationally impossible
> afaik.  I don't think the "standard" GNU password program will let you
> use a dictionary word as a password.  Given that, the universe of
> passwords is not crackable on a single machine, that is, even if you
> get a distributed attack, there's still a single machine (the computer
> under attack) doing the password checking.

It's easy to override if you're root (the "use a good password rule") 
and I think it's PAM that forces this rule, not passwd itself, but 
that's just semantics.

> And, if you come under a distributed attack, I assume you might see a
> high load average, and your system will issue warning alarms.  You can
> also rate limit the requests per second to the ssh port, although it's
> not clear this is necessary.

Seen Pentium I's brought to their knees with SSH attempts... but nothing 
modern.  :-)

> A couple of important things we set in the sshd_config that isn't set
> by default:
> 
>     VerifyReverseMapping yes
>     PermitRootLogin no

Still might kill a Pentium I.  :-)  Also some distros do set the latter 
setting by default, I believe.  Again, just comments and semantics.  No 
disagreement here.

> This prevents a lot.  We also limit the access to the machines which
> can be accessed via certain networks for all but a couple of
> machines, and those "open" machines have limited data on them.

Always smart.  Sometimes having the machine accessible from the 
"Internet at large" is appropriate, but rarely.

> We don't use ssh keys except for automated logins, but those logins
> are sandboxed with scponly, and they aren't root logins, and they
> don't have any privs except to look at the files they have already
> rsynced.

I'm torn on this one.  I've gone both ways, automated logins and not. 
You really have to keep the "trusted" machine very secure if you go that 
route, though.  I have done it from private internal protected networks 
at work before, but I cringe a little at allowing say, my laptop to do 
it.  If I felt it worth the time to password protect the BIOS, the boot, 
and encrypt the filesystems... maybe then... but that's an awful lot 
more work than just remembering a good password.

> Keys stored on disk are therefore not more secure.  Indeed, they are
> more convenient to login if you use ssh-agent (see below), which most
> people do.  Even if you don't use ssh-agent, they key can be subject
> to a local exploit that leads to a remote exploit.  If you only use
> passwords, and you require the "open" ssh machine login to have a
> different password than the "inside" machines, you have higher
> security, because no local information on the the "open" machine can
> be exploited to gain access to the "inside" machines.  And, if you
> tunnel your ssh sessions (LocalForward <port> inside.my.com:22) from
> the outside machine to the the inside machines, you aren't subject to
> sniffing on the "open" machine even if it is cracked.

Uh-huh.

> ssh-agent is a convenience, and therefore easily exploited.  Once you
> have root access on the "open" machine, all "inside" machines are
> yours with nothing to stop you.  It's the "soft, chewy center"
> problem.

That's the crux of the problem I've run into with it too, absolutely. 
You have to be ultra-careful with the "trusted" machine.

> Security is very tricky, but at the root of all secure systems is a
> password.  You should have a password for different classes of access
> ("open", "inside", "su", imap, random website, etc.).  You should only
> have a few of them so you can remember them without writing them down,
> and you should change them often.

Security only becomes less tricky when nothing runs or requires root 
access... that helps a whole lot.  Then a very few sudo rules for those 
things that are REQUIRED to be done by root... the more uptime is 
important ($$$$ or SLA's or just overall uptime) the less anyone should 
ever access the box as root, generally.  That hasn't changed in 20 
years, though.  But we all get lazy about it.

> My rule of thumb is this: If you can change an access level without a
> human (or crypto device) entering a new password, you have a security
> hole.

Probably.  I'm sure some will debate it, but I generally agree with 
you... for whatever that's worth.  I don't like stored passwords or keys 
for this reason.

Nate