When deploying services like Glassfish or other application servers on CentOS, system administrators often need to create service accounts that shouldn't be directly accessible. However, we still require the ability to su into these accounts for maintenance and debugging purposes. This configuration provides security while maintaining operational flexibility.

CentOS uses /sbin/nologin as a special shell that prevents interactive login while still allowing the account to exist. Here's how to implement it:

# Create the restricted user
sudo useradd -s /sbin/nologin serviceuser
# Set password if needed
sudo passwd serviceuser

After setting this up, verify it works as intended:

# Attempt SSH login (should fail)
ssh serviceuser@localhost
# Attempt su from root (should succeed)
sudo su - serviceuser -s /bin/bash

For even stricter restrictions, you can use /bin/false instead:

sudo usermod -s /bin/false serviceuser
# Then access via:
sudo su - serviceuser -s /bin/bash

To explicitly block SSH access while allowing local su:

# Edit /etc/ssh/sshd_config
Match User serviceuser
    PasswordAuthentication no
    PermitEmptyPasswords no
    PermitRootLogin no
    ForceCommand /bin/false

Here's how this would work for a Glassfish service account:

# Create the restricted account
sudo useradd -s /sbin/nologin -d /opt/glassfish glassfish
sudo chown -R glassfish:glassfish /opt/glassfish

# Start service as the restricted user
sudo -u glassfish /opt/glassfish/bin/asadmin start-domain

If you encounter problems with su:

• Ensure PAM is properly configured in /etc/pam.d/su
• Check group memberships with groups serviceuser
• Verify SELinux context if enforced

When managing services like Glassfish or other Java EE containers on CentOS 6, it's often necessary to create dedicated service accounts that:

• Cannot be logged into directly via SSH or console
• Allow privileged users to su into the account for maintenance
• Maintain proper file ownership and process isolation

CentOS provides the /sbin/nologin shell specifically for this purpose. Here's how to implement it:

# Create the service account
sudo useradd -s /sbin/nologin glassfish_user

# Verify the shell assignment
grep glassfish_user /etc/passwd

By default, accounts with nologin shells can't be accessed even via su. To enable this:

# Edit the PAM configuration
sudo vi /etc/pam.d/su

# Add or modify this line to include your admin group
auth sufficient pam_wheel.so trust use_uid group=wheel

For a Glassfish installation scenario:

# Create the account with proper home directory
sudo useradd -m -d /opt/glassfish -s /sbin/nologin glassfish

# Set ownership for Glassfish installation
sudo chown -R glassfish:glassfish /opt/glassfish

# Test su access (as root or wheel member)
sudo su - glassfish -s /bin/bash

• Always use sudo for privilege escalation
• Restrict su access to specific admin groups
• Monitor authentication logs at /var/log/secure
• Consider SELinux contexts for service accounts

If you encounter "This account is currently not available" errors:

# Check the shell assignment
getent passwd username

# Verify PAM configuration
cat /etc/pam.d/su | grep pam_wheel

# Test with explicit shell override
su - username -s /bin/bash