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

One stray plus sign in /etc/hosts.equiv turns a host-specific trust rule into passwordless login for anyone, from anywhere. This creates a narrowly scoped rule for legacy r-commands, checks the file's permissions, and tests it 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 step and does not need 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, and it is not a reason to 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 entirely.

2. Choose one narrow rule

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

backup.example.net

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

backup.example.net backup-agent

• Use the second form sparingly. Only reach for it when that wider account mapping is genuinely required.
• Usernames are not scoped. A username in this file is not restricted to the same-named local account.
• Root is excluded. 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 live 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, so run it 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, and never type a standalone plus sign. In this syntax, + means any host, so one typo turns a host-specific policy into a system-wide trust rule. +host is also not valid syntax for allowing every user from one host; write host + for that instead, understanding that it allows any user from that host.

4. Put denials before allows

Rules are read top to bottom, and processing stops at the first match, so a deny entry 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 example above.

5. Check ownership and permissions

Some systems honour the file only when it is owned by root and not writable by anyone else, and 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

Expect 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 widen permissions merely to make a service accept the file. A refusal caused by stricter ownership checks is safer than silently loosening 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 that service accepted the rule, but not that every other service uses the same policy.

Modern systems use PAM. The manpage says 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 any attempts made while the unsafe rule was live. If you no longer need trust-based access, remove the file only after confirming the service has another supported authentication path: deleting it on a whim can disrupt existing automation.