When administering Linux servers remotely, we often need to execute privileged commands. A common scenario is checking hardware information like BIOS version using dmidecode, which requires root access. The straightforward approach:

ssh remote-server su -c "dmidecode -s bios-version"

Fails with the frustrating "standard in must be a tty" error. Let's explore why this happens and robust solutions.

Traditional Unix systems require a terminal (tty) for security-sensitive operations like su. This prevents:

• Automated password harvesting
• Privilege escalation in non-interactive sessions
• Potential security vulnerabilities in batch operations

Solution 1: Force Pseudo-Terminal Allocation

The simplest fix is adding SSH's -t flag:

ssh -t remote-server "su -c 'dmidecode -s bios-version'"

This forces pseudo-terminal allocation, satisfying su's requirement.

Solution 2: Modify sudoers Configuration (If sudo is Available)

For systems where you can use sudo, create a secure configuration:

# /etc/sudoers.d/dmidecode
youruser ALL=(root) NOPASSWD: /usr/sbin/dmidecode -s bios-version

Then execute remotely:

ssh remote-server "sudo dmidecode -s bios-version"

Solution 3: SSH Direct Root Login (Not Recommended)

If you must use root credentials:

ssh -o PreferredAuthentications=password -o PubkeyAuthentication=no root@remote-server "dmidecode -s bios-version"

Warning: This exposes root credentials in command history and process listings.

Solution 4: SSH Config Modification

For frequent access, add to ~/.ssh/config:

Host bios-check
    HostName remote-server
    User youruser
    RequestTTY force
    RemoteCommand su -c 'dmidecode -s bios-version'

Then simply run:

ssh bios-check

For environments where none of the above work:

• Create a setuid wrapper script (security risk)
• Use expect scripts (complex but flexible)
• Deploy SSH certificates with forced commands

Always consider:

• Principle of least privilege
• Command logging requirements
• Potential exposure of sensitive data
• System hardening implications

---

When managing RedHat Enterprise Linux 4 servers remotely, administrators often encounter the "standard in must be a tty" error when attempting to execute privileged commands through SSH. This particularly affects BIOS version checks via dmidecode which require root access.

RHEL 4's security model enforces TTY requirements for su operations by default. This prevents potential security vulnerabilities but creates obstacles for automation scripts.

The most straightforward fix is to force pseudo-terminal allocation with the -t flag:

ssh -t remote-server "su -c 'dmidecode -t bios'"

For environments where -t doesn't work, try command chaining:

ssh remote-server "echo 'PASSWORD' | su -c 'dmidecode -s bios-version'"

Warning: This exposes the password in shell history. Consider using SSH keys instead.

Edit /etc/pam.d/su and comment out the line:

# auth required pam_securetty.so

This disables TTY checking system-wide.

Add to your ~/.ssh/config:

Host remote-server
    RequestTTY force

#!/bin/bash
REMOTE_HOST="remote-server"
REMOTE_USER="admin"
BIOS_CMD="dmidecode -t bios"

ssh -t ${REMOTE_USER}@${REMOTE_HOST} "su -c '${BIOS_CMD}'"

• Ensure dmidecode is installed on the remote server
• Verify SELinux isn't blocking the operation
• Check /var/log/secure for authentication failures