Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 2 May 2003 10:43:13 +0100
From:      Matthew Seaman <m.seaman@infracaninophile.co.uk>
To:        Fedder Skovgaard <fsk@maerskdata.dk>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: Being root via ssl
Message-ID:  <20030502094313.GA11643@happy-idiot-talk.infracaninophile.co.uk>
In-Reply-To: <OFAEF92425.1AC61264-ONC1256D1A.00311AA3-C1256D1A.0032A2DF@mdata.dk>
References:  <OFAEF92425.1AC61264-ONC1256D1A.00311AA3-C1256D1A.0032A2DF@mdata.dk>

next in thread | previous in thread | raw e-mail | index | archive | help

--NzB8fVQJ5HfG6fxh
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 02, 2003 at 11:13:13AM +0200, Fedder Skovgaard wrote:

> I've got a 5.0-release box running remotely, and access it through ssl. I=
=20
> (obviously) created a default user account for day to day work, but=20
> discovered that I wasn't able to "su" when logged in via ssl.=20

I take it you mean 'ssh' rather than ssl.

Once you've logged in via ssh (or any other mechanism), you have full
access to all the permissions of your account.  Thus if you can't su
to root from a ssh session, then it's more than probable that you
couldn't su even if logged in to that account on the console.

Now, the reason that you can't su from your personal account is a FAQ:
you need to be a member of group 'wheel' before you can do that.

To make yourself a member of the wheel group, log in as root and:

    # pw group mod -n wheel -m fsk

and when you log into the fsk account again, you should be able to su.
=20
> The only way I (As a newbie) could be able to change to root was to allow=
=20
> direct root login via ssl, which was documented as being something one=20
> quite seldomly would want to do.

Yes. This is true.  For interactive logins a) you really don't want to
run as root for the whole session, just for those commands that
require root priviledge and b) requiring people to log in under their
own UIDs and then use su(1) or sudo(8) or equivalent establishes an
audit trail which is invaluable when it all goes horribly wrong.

However, this is not a hard and fast rule, and local ideosyncrasies
may override common sense.

Note that a) applies just as well to logins via the console as well as
via the network.  However, don't even think about locking root out of
console logins unless you fully understand the consequences.

> What is the preferred way of doing this, and is it _really_ dangerous to=
=20
> allow root login via ssl ?

Make a rule to always log in under your own user ID, and then only use
su(1) absolutely when necessary: preferably for single command lines
only.  Even better is to install sudo(8) or super(8) from the ports,
which allow you to set up nominated users to run commands with root
privilege but without having to hand out the root password.  This is a
good idea even if it's your own personal machine and you are the only
user.

The one great exception to all this is where you need to remotely run
a privileged command via ssh *automatically* and without user
intervention to type in passwords -- eg. to kick off a backup in the
middle of the night.  In this case you should use ssh key based
authorization: generate a passwordless key pair for root, but use the
'command=3D/foo/bar/baz' syntax in root's authorized_keys file to limit
what can be run via that particular key.

	Cheers,

	Matthew

--=20
Dr Matthew J Seaman MA, D.Phil.                       26 The Paddocks
                                                      Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey         Marlow
Tel: +44 1628 476614                                  Bucks., SL7 1TH UK

--NzB8fVQJ5HfG6fxh
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE+sj2xdtESqEQa7a0RAmoiAJ9CyxCA9v5KhZ76DF3tQ3S5DY3e3gCcC9sa
gEQcDP0xquYOoapYym+7xxQ=
=DZt9
-----END PGP SIGNATURE-----

--NzB8fVQJ5HfG6fxh--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030502094313.GA11643>