Technical Analysis and Security Practices for Setting Blank Root Password in SliTaz

Technical Background and Problem Analysis

In Linux systems, user password management is a core component of system security. SliTaz, as a lightweight Linux distribution, uses Dropbear as its SSH server implementation, which differs from OpenSSH in configuration and behavior. The "password was too short" error encountered when attempting to set a blank password via the passwd command reveals the system's basic validation mechanism for password length.

Password Storage Mechanism Analysis

Linux systems use the /etc/shadow file to store encrypted password hashes for users. When the passwd command is executed, the system invokes PAM (Pluggable Authentication Modules) for password policy validation, including minimum length and complexity requirements. Blank passwords (pressing only Enter) are typically rejected because most PAM configurations require passwords to contain a minimum number of characters.

Technical Solutions for Implementing Blank Passwords

Using passwd Command to Delete Password

The most direct method is using the passwd -d root command. This command removes the password hash field for the root user from /etc/shadow, theoretically allowing passwordless login. However, the actual effect depends on the system's PAM configuration and SSH server settings.

Setting Blank Password via chpasswd

When the passwd command rejects blank passwords, the chpasswd tool can bypass some validation:

echo root: | chpasswd

If the above command is rejected, one can attempt to generate a hash for an empty password:

echo "root:$(mkpasswd -s </dev/null)" | chpasswd -e

Here, mkpasswd -s reads the password from standard input (empty in this case) and generates the corresponding encrypted hash, while chpasswd -e indicates that the input password is already in encrypted format.

SSH Server Limitations and Configuration

Even with a successfully set blank password in /etc/shadow, Dropbear or OpenSSH may still require password authentication due to independent security policies:

• PasswordAuthentication no: Completely disables password authentication, forcing key-based authentication
• PermitRootLogin no: Prohibits root user login via SSH
• PermitRootLogin prohibit-password: Allows root login but prohibits password use (requires keys)
• PermitRootLogin forced-commands-only: Only allows execution of predefined commands

Security Risks and Best Practices

⚠️ Critical Warning: Setting blank passwords on internet-connected systems is extremely dangerous. Attackers can easily gain complete system control. Consider such configurations only in isolated test environments or dedicated networks.

Recommended secure alternatives:

1. SSH Key Authentication: Generate SSH key pairs, add public keys to ~/.ssh/authorized_keys, and use ssh-agent for convenient passwordless login.
2. sudo Privilege Delegation: Create regular users with sudo privileges and disable direct root login: passwd -l root locks the password, passwd -u root re-enables it.
3. Principle of Least Privilege: Assign root privileges only for necessary operations, using regular accounts for daily tasks.

Troubleshooting and Recovery Strategies

Before modifying password configurations, ensure backup login methods:

• Maintain at least one backup user with sudo privileges
• Preserve physical or console access
• Test configuration changes in virtual or recoverable environments

System Component Interaction Analysis

User authentication involves collaboration between multiple components:

SSH Client → Dropbear/OpenSSH → PAM → /etc/shadow → Kernel Permission Verification

Security policies at any stage may prevent blank password login. Detailed configuration options for each module can be explored via man shadow, man sshd_config, and man pam.

Ultimately, balancing security and convenience requires informed decisions based on specific use cases. In most production environments, strong password policies or multi-factor authentication are essential security baselines.