Date: Wed, 26 Jun 2002 18:41:19 +0200 From: Patrick Atamaniuk <patrick-lists@atabersk.de> To: Robin Smith <rasmith@aristotle.tamu.edu> Cc: freebsd-security@FreeBSD.ORG Subject: Permit root login, was Re: OpenSSH hole Message-ID: <20020626184118.A16530@mail.atabersk.de> In-Reply-To: <200206261326.g5QDQb8t090120@aristotle.tamu.edu>; from rasmith@aristotle.tamu.edu on Wed, Jun 26, 2002 at 08:26:37AM -0500 References: <200206261326.g5QDQb8t090120@aristotle.tamu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
--HcAYCG3uE/tztfnV
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi,
=2E..
Robin Smith(rasmith@aristotle.tamu.edu)@2002.06.26 08:26:37 +0000:
>=20
> However, if the connecting user happens to be root (i.e. if
> PermitRootLogin is on), then there's no split (and even if there were,
> both would be owned by root, of course). I haven't heard anything
=2E..
sorry going off topic, but here my 2cent:
Though i don't know the effect on privsep, i generally recommend
don't permit root-login.
Have administrative users without valid passwords but not empty passwords
( * in the password field) using ssh keys
and invite only them into wheel. Only the root account should have=20
a (secure, complicated) password for 'su' and console login.
Even if you need root-login for automated adminstration purposes, this
can be done with root-login disabled by using ssh-keys in combination with
the command=3D"" parameter in the authorized_keys file.
Reasoning:
Always assume your (master)passwordfile is compromized. Assume i'ts public=
:)
Getting onto the machine by using social engeneered or otherwise
obtained passwords is simply not possible due the absence of passwords.
Knowledge of the root password does not help if you don;t have pysical acc=
ess or a
ssh-key to an admins account if no user even has a password.
If the attacker has physical access, we are lost anyways (bios password=20
may help but might have disadvantages if you are colocating)
Of course the private keys for the administrative clients
must be protected by passphrase and site policy.
I think i stole that idea from FreeBSD handbook:)
regards,
/p
--=20
regards,
Patrick
----------------------------------------------------
Patrick Atamaniuk patrick@atamaniuk.de
http://www.atamaniuk.de
http://www.top-c.de
----------------------------------------------------
80B0BCF6 D/E D624 96A8 22A9 1ED2 77F3 A0C5 78C0 14F9 80B0 BCF6
My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/
Please do not remove my address from To: and Cc: fields in mailing lists.
--HcAYCG3uE/tztfnV
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE9Ge6teMAU+YCwvPYRAowwAKD6bVD6YmnBpkG1bUeyjESbz1JiDACeKFhI
XJbNhFDM4KJa0YvPp+F3XSI=
=1+YP
-----END PGP SIGNATURE-----
--HcAYCG3uE/tztfnV--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020626184118.A16530>