ssh default security risc

[Ted Mittelstaedt]

> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org]On Behalf Of Giorgos
> Keramidas
> Sent: Thursday, February 03, 2005 10:01 PM
> To: Gert Cuykens
> Cc: freebsd-questions at freebsd.org; Chris Hodgins
> Subject: Re: ssh default security risc
>
>
> On 2005-02-04 01:04, Gert Cuykens <gert.cuykens at gmail.com> wrote:
> > On Fri, 04 Feb 2005 00:05:34 +0000, Chris Hodgins
> > <chodgins at cis.strath.ac.uk> wrote:
> > True but the point is without the ssh root enabled there is nothing
> > you can do about it to stop them if they change your user password
>
> What user password?  You are using SSH keys, as many have noted in
> earlier posts of the thread, right? :P
>
> Seriously now.  What gave you the crazy idea that having local
> access as
> an unprivileged user means that automatically you are also
> root?  Effort
> is *still* needed.  Effort that the average Joe Random Cracker is _NOT_
> going to spend.
>
> You may also want to consider than having SSH enabled for root means
> there is only ONE step at becoming root from any remote location.
>
> Having to SSH as a user first, with the right combination of SSH keys
> and passwords, and then use su(1) with yet another password is at least
> one more step.
>
> Why is the first, 1-step procedure safer than the second?
>

I think I'm going to interject a few things here to this discussion,
which has turned into a rediculous religious argument.

In answer to your question about a 1-step procedure safer than the
second,
well as a matter of fact there are circumstances when it is.  For
example:

1) When the ssh install that permits root login is using ipfw or tcp
wrappers
to restrict incoming ssh to a defined IP address, compared to a ssh
installation
that doesen't permit root login that allows incoming ssh from any IP in
the
world.

2) When the ssh install that permits root login is using an authorized
keys
file that only permits the root user to ssh in from a host defined with a
canonical name, compared to a ssh installation that disallows root login
and
doesen't restrict by hostname for ordinary users.

3)  When the ssh install that permits root login has a /root/.ssh/rc that
specifies
a specific command that exits and closes the session after being run, and
blocks all ordinary users from sshing in, compared to a ssh installation
that doesen't permit root login that allows ordinary users to spawn a
shell.

Now, these are just 3 examples I can think of off the top of my head.
And I'm
sure your going to squawk dirty pool, and claim that you wern't meaning
these
'spechel cases' that are exceptions, excuse, excuse, excuse.

The point is that making blanket inferences like your doing, such as that
disabling root ssh is always more safer than allowing it, is very risky.
There
are -very few- instances in computer security where a blanket statement
always applies.  Each scenario must be analysed independently, with an
eye
to -every possible vector- that an attacker can take.

I repeatedly see lots and lots of times on this list people bragging
about
constructing these byzantine security blankets for remote access to their
servers, and at the same time bragging about being too much a cheapskate
to
bother paying the few bucks a month to their ISP to get a static IP
assignment for their clients, as if the entire paradigm of access list
restrictions somehow doesen't exist.  Not to mention that even without a
static IP assigned
to your home or other locations that you normally ssh in from, it's
pretty
simple to block off huge chunks of the Internet, particularly blocks
assigned
to Red China, where a huge amount of cracking and spamming originates
from.

Well let me tell you this, if your idea of securing your machine is to
follow a few axioms that you picked up here and there, then good luck.
The day that the thief makes off with your laptop/desktop/whatever that
you left behind a door that you accidentally forgot to lock, or the
joker down the hall gets the worn out backup tape out of your garbage
that
you didn't bother to erase, or the cracker installs a remote control
program
with a keyboard logger on that Windows box in the lab that you run Putty
on every once in a while to get into your own systems, you are
going to come to the sudden realization that you really didn't know
anything
about what you were thinking.

Ted