Configure /etc/hosts.equiv Without Opening r-Commands to Everyone

You will create a narrowly scoped /etc/hosts.equiv rule for legacy r-commands, check the file's permissions, and test the rule without accidentally granting access to every host. Allow about 10 minutes if you already know the trusted host's fully qualified domain name. The examples target Linux man-pages 6.7, shipped here by the Debian manpages package version 6.7-2.

1. Check the service and existing rule

Inspect the current file before editing it. This is a read-only command and does not require elevated privileges if the file is readable:

sudo sed -n '1,120p' /etc/hosts.equiv
sudo stat -c '%A %U:%G %n' /etc/hosts.equiv

If the file does not exist, that is not an error. Do not create a broad replacement just to make the path appear. The local manpage describes /etc/hosts.equiv as the system-wide list; a user's ~/.rhosts file is a separate mechanism.

2. Choose one narrow rule

Use the trusted host's fully qualified domain name, not its short name. Replace backup.example.net with a real name under your control. A hostname on its own permits users from that host to access the matching local account without a password:

backup.example.net

The second field changes that boundary. This permits the named user from the host to access any non-root local account without a password:

backup.example.net backup-agent

Use the second form only when that wider account mapping is genuinely required. A username in this file is not restricted to the same-named local account, and the manpage explicitly excludes root from this grant.

Netgroups are also supported. For example, +@operations permits matching local users from hosts in the operations netgroup. Netgroup membership and name-service configuration are outside this file, so verify them separately before relying on the rule.

3. Edit the file as root

Make a recoverable backup, then replace or edit the file with elevated privileges. The backup command changes state and should be run only when you have enough disk space and a protected destination:

sudo cp --preserve=mode,ownership,timestamps /etc/hosts.equiv /etc/hosts.equiv.backup
sudoedit /etc/hosts.equiv

Keep the file to the smallest useful set of rules. Do not type a standalone plus sign. In this syntax, + means any host, so one typo can turn a host-specific policy into a system-wide trust rule. The string +host is not valid syntax for allowing every user from one host; write host + for that case, understanding that it allows any user from that host.

4. Put denials before allows

Rules are read from top to bottom and processing stops at the first match. A deny entry therefore has to precede the broader allow entry it is meant to narrow. This example allows matching local accounts from the host except for baduser:

backup.example.net -baduser
backup.example.net

To deny the entire host, use a host-level minus:

-backup.example.net

-host -user is not a valid way to deny one user from one host. Put the user denial beside a positive host rule instead, as in the previous example.

5. Check ownership and permissions

Some systems honour the file only when it is owned by root and is not writable by anyone else. The local manpage also notes that exceptionally strict systems may reject files with additional hard links. Check the result:

sudo stat -c '%A %U:%G %h %n' /etc/hosts.equiv

The expected output should show root root, no group or other write bit, and a hard-link count of 1 on systems enforcing that extra check. If ownership or mode is wrong, correct it with elevated privileges:

sudo chown root:root /etc/hosts.equiv
sudo chmod go-w /etc/hosts.equiv

Do not add permissions merely to make a service accept the file. A refusal caused by stricter ownership checks is safer than silently widening write access.

6. Verify the effective authentication path

There is no standalone syntax checker in the local manpage, and the r-command clients are not necessarily installed. Review the file first, then make one controlled connection from the named host using the exact service you intend to support. Record the result and check the service logs on both machines. A successful connection proves the service accepted the rule, but it does not prove that every other service uses the same policy.

Modern systems use PAM. The manpage says that a standalone + is treated as a wildcard only when promiscuous is present on the relevant service's PAM auth line, such as for rlogin. Do not infer PAM behaviour from the hosts file alone. Inspect the service-specific PAM configuration and its daemon documentation before testing any wildcard or relying on passwordless access.

Undo an unsafe change

If a test exposes an overly broad grant, stop the affected r-service if your operating procedure requires it, restore the backup, and recheck the file:

sudo cp --preserve=mode,ownership,timestamps /etc/hosts.equiv.backup /etc/hosts.equiv
sudo stat -c '%A %U:%G %h %n' /etc/hosts.equiv

After restoring, repeat the controlled connection test and review logs for attempts made while the unsafe rule was present. If you no longer need trust-based access, remove the file only after confirming that the service has another supported authentication path; deleting it can disrupt existing automation.