> 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,
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.

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

   > 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.
   
   > 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.


.mrg.