On Tue, 4 Sep 2001, matthew green wrote:

>    > the issue isn't about whether ssh is secure enough for not.  it's about
>    > being *consistent* within our own set of tools.
>
>    Yes, actually, it is about whether ssh is secure enough. Because as I said
>    in a note to Curt, for years we have babbled on (when talking about
>    default configs, etc.) about "secure" terminals, not "physically local"
>    ones. So if ssh gives us a connection which "we" consider "secure", then
>    we *are* being consistent within our own tools in allowing root to login.
>
> so what about kerberised telnet?  why don't we allow that?  also,

Probably because kerberized telnet was 1) never as popular across the
board as ssh (I know of a number of places which use it extensivly, but
they are the minority), and 2) kerberized telnet grew out of
non-kerberized telnet, an insecure protocol, and kerberized telnet never
permitted the, "telnet is ok but root needs kerberos," control. Oh, (MHO)
and 2a) kerberized telnet grew out of non-kerberized telnet, which has a
bad name.

It's a seperate thread, but a disabled inetd.conf line showing how to
enable kerberized-only telnet ("telnetd -ax" as I recall) would probably
be a good thing.

> i don't agree with your interpretation of "secure".  it is actually
> well defined in ttys(5):
>
>        secure   If on is specified, allows users with a uid of 0 (e.g. "root")
>              	to login on this line.

True. And that definition disagrees with both you and me. :-) That
definition is very practical - "secure" has nothing to do with physical
access or login method (direct vs ssh vs telnet vs kerberized telnet),
just the decision of the admin. It's more a definition by fiat.

> sshd doesn't even consult this, it has has a global all or nothing
> switch.

Nor should it consult /etc/ttys, IMHO :-) Pseudo terminals don't have the
physical mapping abilities that real terminals do. So I can't see any way
that there can be any way to differentiate the security of one pty from
another (you need the connection info, ssh, telnet, rsh, etc., about what
is on the other side of the pty, which the abstraction is designed to deny
you). So since there is no relevant info there, I don't see what
consulting /etc/ttys would buy us. :-)

>    > until ssh was integrated into netbsd, it was virtually impossible for
>    > anyone to login as root except on the console, until that ability was
>    > configured by the sysadmin.  ie:
>    >
>    > 	- add users
>    >
>    > 	- add users to group wheel (or remote all entries from group
>    > 	  wheel)
>    >
>    > 	- tell users root password.
>
>    Uhm, it still is as you described. By default, we do not enable sshd. So
>    for someone to be able to log in as root via ssh, the admin had to sit at
>    the above mentioned console and enable ssh.
>
> and at that point *anyone* can access the machine as root.  all they
> need to do is steal single password.  or guess it.  today, even if i
> were to enable all network login daemons and tell people my root
> password, they couldn't get in without first having logged in as a
> user or on a "secure" (as marked by /etc/ttys) pty.

As above, I think that "secure" being defined exclusivly as being marked
as "secure"  in /etc/ttys is a poor definition. Network connections (and
ptys) strike me as having fundamentally different naming dynamics from the
non-network ones. It would be different if our main form of networking
involved something like permanent virtual circuits, then a pty tied to a
pvc would make sense to be in /etc/ttys. But inet is (thankfully!) quite
different. So it strikes me as comparing apples and oranges, which I don't
understand.

>    > and still they could only access root via a physical console or after
>    > having already authenticated themselves.  when ssh was integrated, all
>    > that one needs is for sshd to be enabled and the root password to be
>    > known.  this *totally* changes the NetBSD default.  and that's why it
>    > has been changed to not permit root login.  *not* ssh vs. anything else
>    > but *self consistency in NetBSD*.
>
>    "Self consistency" does not cut it as a reason. What we had before was
>    arguably self consistent (as evidenced by the fact I am arguing that it
>    was self consistent :-) .
>
> i don't see how allowing people to login as root via one method and
> not another can be considered self consistent.  encrypted logins are
> not new to netbsd.  ssh is.  and ssh was the inconsistent part.

In terms of being in the base, though, aren't both ssh and kerberos the
same age? I thought 1.5 was the first release both with kerberos (and
other hard crypto) in the main tree, and the first one with ssh built in.
Not enabling kerberized telnet by default, even if it is considered
"secure" enough, would be a bad idea if the default telnetd didn't support
kerberos, as was the default when we had seperate crypto.

Also, there are two ways to solve the inconsistency you describe, the
other being to add kerberized telnet as a default. :-)

Take care,

Bill