[lug] root password
nate at natetech.com
Wed Aug 2 16:09:52 MDT 2006
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
> 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
> 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
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.
> 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"
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
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.
More information about the LUG