rsh

What it does

rsh ("remote shell") executes a command on a remote host, or opens an interactive shell if no command is given, using the same unencrypted, host-based trust model as rlogin. It's one of the classic BSD "r-commands" (alongside rlogin and rcp) that were the standard way to run remote commands on Unix networks before SSH existed. Like its siblings, it transmits everything in clear text and can rely on .rhosts/ hosts.equiv trust files instead of real authentication, which is why it's obsolete and considered a security liability on any network that isn't fully isolated and trusted.

Beginner examples

• rsh host2 uptime — run uptime on host2 and print the output locally
• rsh -l alice host2 'whoami' — run a command as a specific remote user
• rsh host2 — with no command given, opens an interactive remote shell (behaving like rlogin)

rsh host2 df -h

Advanced examples

• Run a command as a specific remote user: rsh -l svc-account host2 'systemctl status app'
• Redirect input from /dev/null so a backgrounded rsh job doesn't hang waiting on stdin: rsh -n host2 'backup.sh' &
• Chain remote command output directly into a local pipeline: rsh host2 'cat /var/log/app.log' | grep ERROR

rsh -l svc-account host2 'tail -n 100 /var/log/app.log'

Common mistakes

• Running rsh against any host reachable from an untrusted network — its lack of encryption exposes both the command and its output (and any credentials involved) to anyone on the network path.
• Relying on .rhosts/hosts.equiv trust and assuming that's equivalent to real authentication — it trusts a claimed source host/user, which is spoofable.
• Confusing rsh with the Korn/Bourne "restricted shell" mode (also sometimes called rsh as a shell name, /bin/rsh symlinked to a restricted bash/ksh) — same command name historically, completely different, unrelated tool.
• Assuming a modern distro ships rsh — most don't install the rsh-client/ rsh-server packages by default anymore.

Tips

• If you see rsh host command in an old script, the direct modern equivalent is ssh host command — the calling convention is nearly identical.
• Double-check whether "rsh" in a given context refers to the remote-shell network command or a restricted local shell — the name is genuinely overloaded in Unix history.
• Audit for and remove .rhosts/hosts.equiv files alongside any rsh usage found during a security review; they usually go together.

Best practices

• Never enable rshd on a network segment that isn't fully isolated and trusted end to end.
• Replace any remaining rsh host command automation with ssh host command, ideally using a dedicated key pair scoped to only the commands that automation needs.
• Treat discovery of rsh usage or rshd running in production as a security finding requiring remediation, not just a style/modernization nit.

Real-world use cases

• Identifying and replacing rsh-based automation (old cron jobs, cluster job submission scripts) during infrastructure modernization or a security audit.
• Historical/educational context when studying the evolution of Unix remote access tools from r-commands to SSH.
• Explaining in an interview why finding rshd enabled on a host during a penetration test is a critical-severity finding.

Common interview questions

• What's the difference between rsh and rlogin? rsh is built to run a single remote command and exit (falling back to an interactive shell only if no command is given); rlogin always opens an interactive login session.
• Why is rsh considered insecure? It transmits everything unencrypted and commonly authenticates via host-based trust files (.rhosts/hosts.equiv) rather than a verified credential, making it vulnerable to spoofing and eavesdropping.
• What's the direct modern replacement for rsh host command? ssh host command — same calling convention, but encrypted and with real authentication.