When automating tasks across multiple machines, combining SSH and sudo privileges presents a unique challenge. The common approach of chaining commands often fails because:

• Interactive sudo prompts break automation
• Command quoting gets tricky with multiple hops
• Input/output streams behave unexpectedly

Here are three reliable methods to achieve SSH-to-sudo execution:

Method 1: Direct Sudo Command

ssh -t myuser@machine.net "sudo -u privileged_user cat /path/to/logs" > local_file.txt

Key points:

• -t flag allocates a pseudo-terminal
• Commands must be properly quoted
• Redirection happens on local machine

Method 2: Sudoers File Modification

For frequent access, configure passwordless sudo:

# In /etc/sudoers on remote machine
myuser ALL=(privileged_user) NOPASSWD: /bin/cat /path/to/logs

Then execute:

ssh myuser@machine.net "sudo -u privileged_user cat /path/to/logs"

Method 3: SSH Config + Sudo

For complex workflows, use SSH config:

Host target-server
  HostName machine.net
  User myuser
  RequestTTY force
  RemoteCommand sudo -u privileged_user /bin/bash -i

For production environments consider:

Using SSH ControlMaster

# ~/.ssh/config
Host *
  ControlMaster auto
  ControlPath ~/.ssh/control:%h:%p:%r
  ControlPersist 10m

Error Handling Example

if ! ssh -q -o BatchMode=yes -o ConnectTimeout=5 myuser@machine.net \
  "sudo -u privileged_user test -r /path/to/logs"; then
    echo "Error: Cannot access logs" >&2
    exit 1
fi

• Missing -t flag causing hangs
• Incorrect quoting of remote commands
• Not handling sudo password prompts
• Permission issues with output redirection

For large-scale operations:

parallel-ssh -h hosts.txt -l myuser -A \
  -i "sudo -u privileged_user cat /path/to/logs" > combined.log

---

When automating remote system administration tasks, we often need to combine SSH access with privilege escalation. The naive approach of chaining commands like this fails:

ssh user@host sudo su - privileged_user
# Hangs indefinitely because sudo expects interactive password input

The root issue lies in how sudo handles password input and TTY allocation. When you chain commands through SSH, sudo doesn't receive the expected terminal interface for password prompting.

Method 1: Direct sudo command execution

ssh -t user@host "sudo -u privileged_user cat /path/to/logs" > local_log.txt

Key points:
• -t forces pseudo-terminal allocation
• Quotes wrap the entire remote command
• Output redirected locally

Method 2: Using sudoers NOPASSWD (secure approach)

# On remote machine's sudoers file:
myuser ALL=(privileged_user) NOPASSWD: /bin/cat /path/to/logs

# Then in your script:
ssh user@host "sudo -u privileged_user cat /path/to/logs" > output.log

Method 3: SSH directly as target user (most secure)

ssh privileged_user@host "cat /path/to/logs" > output.log

Requires:
• Direct SSH access configured for privileged_user
• Proper key-based authentication setup

For complex command chains:

ssh -t user@host <<'EOF'
sudo -u privileged_user bash -c '
  cd /app/logs &&
  grep "ERROR" *.log | gzip > errors.gz
'
EOF

Always include proper error checking:

if ! ssh -q -o ConnectTimeout=5 user@host "sudo -u privileged_user test -r /path/to/logs"; then
  echo "Error: Cannot access logs" >&2
  exit 1
fi

For large files, consider compression:

ssh user@host "sudo -u privileged_user cat /large/log | gzip" | gunzip > local_copy