LinuxCommandLibrary

rsh

Execute commands on remote hosts

TLDR

Execute a command on a remote host

$ rsh [remote_host] [ls -l]
copy

Execute a command on a remote host with a specific username
$ rsh [remote_host] [[-l|--user]] [username] [ls -l]
copy

Redirect stdin to /dev/null when executing a command on a remote host
$ rsh [remote_host] --no-err [ls -l]
copy

SYNOPSIS

rsh [-l user] [-n] [-t] [-x] host [command ...]

PARAMETERS

-l user
    Specifies the username to use on the remote host. If omitted, the local username is used.

-n
    Redirects input from /dev/null. This is useful when running rsh in the background.

-t
    Forces pseudo-terminal allocation. This can be useful for commands that expect interactive input or terminal-specific features.

-x
    Disables X11 forwarding. By default, rsh may attempt to forward X11 connections.

DESCRIPTION

rsh (remote shell) is a command-line utility that allows users to execute commands on a remote host without explicitly logging in. It is part of the traditional "r-commands" suite (along with rlogin and rcp) that originated from the Berkeley Software Distribution (BSD) Unix. To establish a connection, rsh relies on a "trusted host" mechanism, typically configured via the /etc/hosts.equiv file on the remote server or a user's ~/.rhosts file. If the client host and/or user are listed as trusted, the remote command is executed without requiring password authentication. While convenient for local area networks with high levels of implicit trust, rsh transmits all data, including usernames and command output, in plaintext. This severe security vulnerability has led to its deprecation on modern systems in favor of more secure alternatives like ssh.

CAVEATS

rsh is considered highly insecure and should be avoided on untrusted networks or for sensitive operations. It transmits all information, including usernames, passwords (if authentication were to occur, though it typically relies on trust), and command output, in plaintext, making it vulnerable to packet sniffing and man-in-the-middle attacks. The underlying trust model, based on IP addresses and hostnames, is susceptible to IP spoofing and DNS spoofing, allowing attackers to impersonate trusted hosts. Due to these critical security flaws, rsh is disabled by default on most modern Linux distributions and is largely deprecated in favor of ssh.

SECURITY IMPLICATIONS

The primary concern with rsh is its complete lack of encryption. All data transmitted between the client and server, including any credentials (though typically authentication is bypassed via trust), commands, and their output, is sent in plaintext. This makes it trivial for an attacker on the same network to intercept and read sensitive information using tools like packet sniffers. Furthermore, the IP-based trust mechanism is vulnerable to IP spoofing, where an attacker can forge their IP address to appear as a trusted host, gaining unauthorized access.

TRUST MECHANISM

rsh relies on a simple, host-based authentication system. On the remote server, two files govern trust: /etc/hosts.equiv and ~/.rhosts.

  • /etc/hosts.equiv: A system-wide file listing trusted hosts and, optionally, users from those hosts who are allowed to execute commands without a password.
  • ~/.rhosts: A per-user file in a user's home directory on the remote host, listing trusted hosts and users who can connect as that specific user.
While convenient, this trust model is inherently insecure as it doesn't verify the identity of the connecting host cryptographically, leading to the vulnerabilities mentioned above.

HISTORY

rsh originated in the early 1980s as part of the Berkeley Software Distribution (BSD) Unix operating system, forming a core component of the "r-commands" suite designed for convenient remote access within trusted local area networks. It gained significant popularity throughout the 1980s and early 1990s as a simple way to automate tasks across Unix systems. However, with the exponential growth of the internet and the increasing demand for secure communications, rsh's fundamental design flaw—plaintext transmission of data and reliance on an easily spoofed trust model—became a critical liability. This led to the development and widespread adoption of the Secure Shell (SSH) protocol in the mid-1990s, which offered robust encryption and authentication, effectively rendering rsh obsolete for secure environments.

SEE ALSO

ssh(1) - Secure Shell client, scp(1) - Secure Copy (file copy over SSH), rlogin(1) - Remote login, rcp(1) - Remote copy (file copy using rsh/rlogin protocol), telnet(1) - User interface to the TELNET protocol

Copied to clipboard