Creating a new SSH user

Access to the cluster from the outside is only permitted using ssh with a public key. This page describes how to add a new account as well as potentially grant it some sort of sudo access. There are a number of security measures that have to be accommodated to make this actually work.

Create user

The usno-serv-1 and the diskless nodes use different system configuration areas, and must be handled individually (the Lustre nodes also have their own).

• To add the user to serv-1 use useradd --disable-password --home UserName. If also adding to the diskless nodes, be sure to make the numerical UIDs match (to change do usermod --uid NumericalUid).
• To add a user to the diskless nodes the files on the diskless image will need to be modified. The easiest way is probably to use a chroot (/etcis mounted readonly so doing it from the diskless nodes doesn't work):
  • chroot /opt/services/diskless_boot/RHEL.6.9.0.X/usno-corr/root /bin/sh
  • Now add the user useradd --disable-password --home /home/usno/users/UserName.

Install ssh key

Get a copy of the users public key and put it into the ~/.ssh/authorized_keys file of the appropriate account. Correlator SSH is configured to only allow ssh login via the public key mechanism so a key will have to be provided. User home directories are located iin /export/home/usno-serv/usno/users on usno-serv-1. These directories are mounted by the diskless nodes and appear as /home/usno/users. Be sure that the protections/ownership on the ~user/.ssh/authorized_keys are appropriate (i.e., user owns the files and the protection of .ssh and authorized_keys prohibits others from writing them); this problem will appear in secure if the LogLevel in sshd_config is set to DEBUG1 or higher. If the numerical UID/GID was changed after user creation it may be necessary to change the UID/GID of all of the files from ~user all the way down.

Ensure SSH access

SSH access is partially controlled by /etc/hosts.allow (a TCP wrappers facility). Only a limited set of hosts are currently permitted to use SSH into the system. If unallowed access is attempted there will be an entry in /var/log/secure saying connection refused from www.xxx.yyy.zzz which is the IP address that was attempting the SSH. This failure will often be the only indication in the secure log file that the connection failed.

Ensure PAM access

If everything else is working, the PAM access mechanism can still prevent access. The server log file will show (depending on the log level) that the key was accepted and but that the connection was rejected for PAM configuration issues. The PAM access control mechanism uses /etc/security/access.conf to limit logins.

Allowing privileged access

If necessary, sudo access can be provided by putting a appropriate file in /etc/sudoers.d. By convention, the file will be named after the user's name (e.g., aUser). See = man sudoers= for more info on setting up the file (there is a file /etc/sudoer which includes the files contained in /etc/sudoers.d; convention prefers adding a file in sudoers.d to create a new sudoers class (makes it easy to revoke or modify if that becomes necessary).

-- JimJacobs - 2017-08-09