[ On Thursday, August 30, 2001 at 11:45:29 (-0700), Bill Studenmund wrote: ]
> Subject: Re: sshd Change: PermitRootLogin = no
>
> Where was the discussion of this change before it happened?

I certainly saw lots of it pass me by...

> I ask because you have implicitly assumed that ssh connections don't count
> as "secure" terminals. That assumption differs from my thoughts on the
> matter, and evidently from the thoughts of the ssh maintaners. Why don't
> they?

If someone in the wheel group logs in via SSH then they really are by
default on a "secure" terminal (in the sense that /etc/ttys means).

The reason being that it's almost infinitely easier to Trojan an SSH
session from a cracked ssh client box than it is to Trojan an RS232
session on a reasonably dumb terminal.  (By "Trojan" I mean do something
nasty without the properly authenticated and authorised user knowing.)

Of course that doesn't mean that PermitRootLogin should be enabled!
Quite the opposite!

With SSH the administrator of the server host MUST implicitly trust
every authorised client host, hardware, software (client & OS), and all,
right from the keyboard switches to the NIC bus interface.  A cracked
client box can covertly take over any SSH session without the user's
knowledge, and it's probably even trival to do this on many types of
client systems.  Indeed the level of trust required is such that if the
client host is a Unix system then you may as well just allow ~/.shosts
and forget all about requiring additional authentication of the user
requesting the connection (unless it's "root") -- if the client host has
already authenticated the user then you might as well authorise the same
user too because that's the real-world level of security given by SSH.

(if you trust the client host, but not the user then you probably won't
have that user in your "wheel" group and you probably don't want to
allow that user to have a ~/.shosts file then you're only slightly
better off by requiring they enter a password -- if you don't trust the
user because they might have left an authorised login session open
unattended then user's account can be Trojaned almost as easily, and
their session might even be used to Trojan the system if a "wheel" group
member might login on the same tty and try to 'su')

(indeed in most cases the client host admin must equally trust the
server host due to the interesting capabilities of the average default
SSH implementation!)

> Also, you have changed an option and said, if you want it the old way,
> change it after an install. Yet you didn't try and find out what portion
> of the NetBSD population will be affected. If most folks want to have no
> root-logins the default, I'll hush. But if most folks want them, doesn't
> it make more sense to leave things as they were?

AFAICR SSH has always come with a warning to not allow root logins even
though the sample configs in 1.2.x and 2.x do have "PermitRootLogin yes".

However for nearly decades now Unix administrators have been warned to
never login directly as root, and NetBSD in particular has reminded us
of this by default on *every* login.

If any significant number of the NetBSD administrating population are
wanting to login directly as root in any fashion whatsoever (i.e. by SSH
or on any other terminal but /dev/console) then I'd be rather surprised
and dismayed.

> Thirdly, I can see one definite advantage to allowing root logins over
> ssh.  When a machine gets to the process limit, non-root users won't be
> alowed to make new processes. Among other things, as I understand it, if
> you're not root, no login. The kernel will, though, let root fork until
> the absolute limit is reached. So there's a usage window where a root-ssh
> can get in to fix things that a regular user su'ing to root can't. Yes, it
> doesn't happen often, but it's an advantage. :-)

If you really 101% trust all the authorised SSH client hosts then you
know how to tune your SSHd config to allow direct root logins to work....  :-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>