[Ref: BSD Certification | User Administration | FAQ 10
Table of Contents
tags: [“Himi Faka-Tonga”, “Hymns”]
If you are new to managing user accounts on OpenBSD, please refer to the above two resources. The BSD Certification, are a very solid grounding in the theory and practise of user administration. Refer FAQ 10 for explicit review of available command-line tools.
These notes discuss general ‘principals’ we currently practise for creating user accounts, more specifics are in the above two posts. Fortunately, computers lend themselves to automation, get the details specified and much of the mundane work can be performed through scripting.
Maximising good construction of your users, works best with a lot of forethought about how your users are created and maintained.
If this is your first 10 hosts, then you may take these with a grain of salt.
We generally have three types of users, which simplifies our
‘standard’ configuration.
With the above classification of users, we can specify group-level privileges, enforced through either “group” allocation, and/or “Login Class” (c.f. login.conf)
In our context, we use login-class to set user resource limits, and user-groups are maintained manually.
What is your policy for access to the host.
We only support host access through SSH Public Key Infrastructure which simplifies account creation, because we generate random passwords. We thus require ssh public keys in our account creation process.
Maintain a validated set of SSH Public Keys. These need to be secured.
Install public keys for all accounts, by:
Some people prefer bash, other zsh, others choose-m.
As we’re a small group, and the ‘corporate’ hosts are border systems, we’ve standardised all user shells on the OpenBSD default ksh (again minimise unnecessary variance.)
Selecting a different shell, implies adding that shell to the list of applications to monitor for vulnerability announcements.
What is your policy for passwords?
We use a known password for the ‘root’ account during installation. The password was generated by a random process (but with not such a long string.) That password is only valid until we confirm admins have ssh key access to the boxes, and sudo has been configured correctly. At this point, well before deployment, ssh root access is disabled and sshd restarted.
[Ref: spew.pl ]
During account creation, we always generated random passwords. Fortunately, our host access policy is secured physical access and mandatory use of SSH Keys, so there is no need for retaining the password or securing their transfer to users.
spew.pl is a perl script using OpenBSD’s /dev/urandom for generating random passwords. The rationale for spew.pl is not to define what is a secure password generator, but an adequate tool using OpenBSD’s base services (i.e. perl and /dev/urandom)
A summary of some of the outcomes from going through the above steps:
* Administrator Accounts
* Users: samt, ...
* Group: usergroup, wheel
* Login Class: staff
* Shell: /bin/ksh
* Regular Accounts
* Users: _monitor
* Group: usergroup
* Login Class: default
* Shell: /bin/ksh
* authpf Accounts
* Users: samt_authpf
* Group: usergroup
* Login Class: authpf
* Shell: /usr/bin/authpf
* Audit
Where usergroup is the user’s private group (we choose to follow old conventions of assigning a usergroup with the same name as the user-account.)
Depending on policy, set the /etc/sudoers configuration appropriately.
Refer sudo(8) and sudoers.html for further assistance.
You may need to perform regular audits of your user account configuration, or it may just be sane to make a cursory review after account creation.
The following are some basic auditing for verifying aspects of the user accounts on your OpenBSD system.
Are there any other users in /etc/passwd with ‘root’ (uid:0) or ‘wheel’ (group-id:0) level priviliges ?
$ sudo grep :0: /etc/passwd
No???! there should only be the below single entry.
root:*:0:0:Charlie &:/root:/bin/ksh
Who are members of the group with ‘wheel (group-id:0) privileges.
$ sudo grep ":0:" /etc/group
Verify that I’m the only one with group-id:0 privileges (and anyone else you wish, of course.)
wheel:*:0:root,samt
Who have we given privileges to in the /etc/sudoers file.
$ sudo grep -v "^#" /etc/sudoers | grep -v "^$" | grep -v "^Defaults"
This is what I have, possibly an insane solution.
root ALL=(ALL) SETENV: ALL %wheel ALL=(ALL) NOPASSWD: SETENV: ALL