Configure pam_rhosts Without Making Remote Trust Too Broad

You will finish with a small, reviewable PAM configuration for the legacy rhosts authentication model, plus a way to check the files and inputs before enabling it. Allow about twenty minutes if the service already exists, or longer if you need to identify which daemon owns the PAM configuration. The installed module here comes from Ubuntu's libpam-modules package version 1.5.3-5ubuntu5.7.

1. Confirm the module and the service

Start with read-only checks. The module is an authentication component, not a standalone command, so there is no executable to run with a test username. PAM applications must set PAM_RUSER and PAM_RHOST before calling pam_authenticate(); the module does not discover the network peer by itself.

$ dpkg-query -W -f='${Package} ${Version}\n' libpam-modules:amd64
libpam-modules 1.5.3-5ubuntu5.7
$ test -r /usr/lib/x86_64-linux-gnu/security/pam_rhosts.so && echo 'module present'
module present
$ ls -l /etc/pam.d/SERVICE_NAME

Replace SERVICE_NAME with the real PAM service, such as the service used by an rlogin or rsh implementation on your host. If the file does not exist, stop here. Creating a new PAM service file without knowing which application will read it can leave the change unused or affect the wrong service.

2. Inspect the trust files before changing PAM

The module consults /etc/hosts.equiv and the target user's ~/.rhosts. The first file describes hosts that are equivalent to the local host. A host entry permits a same-named remote account; a host and user pair can permit a named remote user to access non-root local accounts. A personal .rhosts entry maps a remote-host and remote-user pair to that user's local account.

$ sudo test -e /etc/hosts.equiv && sudo sed -n '1,120p' /etc/hosts.equiv
$ getent passwd TARGET_USER
$ sudo -u TARGET_USER sh -c 'test -e "$HOME/.rhosts" && sed -n "1,120p" "$HOME/.rhosts"'

The first command needs elevated privileges only if the file cannot be read normally. The other checks are read-only, but use the target account's view for its home file. Do not treat a missing file as an error: it means that file contributes no grants.

Look for a standalone +, which means any host in the traditional syntax. It is an especially dangerous typo. Prefer a fully qualified host name and a narrow remote user entry. Deny rules must precede allow rules because the file is processed until the first matching rule. Also check ownership and write permissions:

$ sudo stat -c '%A %U:%G %n' /etc/hosts.equiv
$ sudo find /home/TARGET_USER -maxdepth 1 -name .rhosts -exec stat -c '%A %U:%G %n' {} \;

Keep these files owned by the account that is meant to control them, and do not make them writable by other users. The precise checks enforced by a remote service can differ, so read that service's own documentation before relying on a permission change as a fix.

3. Add the module as an auth rule

Back up the service file, then edit it as root. This is the first state-changing step:

$ sudo cp --preserve=all /etc/pam.d/SERVICE_NAME /etc/pam.d/SERVICE_NAME.before-pam-rhosts
$ sudoedit /etc/pam.d/SERVICE_NAME

Add one auth line in the service's existing authentication stack:

auth    required    pam_rhosts.so

The module provides only the auth type. required means that a failure is recorded, while PAM continues evaluating later rules before returning an overall failure. Do not replace the rest of the stack with the four-line example sometimes shown for an rsh service unless you have confirmed that the application and the host's policy require exactly that stack. A malformed PAM file can deny access, and an overly permissive one can weaken it.

Optional module arguments are debug, silent and superuser=ACCOUNT. Leave them out for the first test. In particular, do not use debug on a busy host without checking where PAM diagnostics will be logged.

4. Check the file and keep a recovery route

There is no universal pam_rhosts dry-run command. The useful validation is the service's own PAM test or a controlled connection from a host and account that you have explicitly listed. Before connecting, verify the edited line and the backup:

$ sudo grep -nE '^[[:space:]]*auth[[:space:]].*pam_rhosts\.so([[:space:]]|$)' /etc/pam.d/SERVICE_NAME
$ sudo test -r /etc/pam.d/SERVICE_NAME.before-pam-rhosts && echo 'recovery copy present'
recovery copy present

Keep an already-open root console or a separate administrative route while testing. If the service begins rejecting valid users, restore the backup and reload or restart the affected service according to its documentation:

$ sudo cp --preserve=all /etc/pam.d/SERVICE_NAME.before-pam-rhosts /etc/pam.d/SERVICE_NAME
$ sudo systemctl reload SERVICE_UNIT

Replace SERVICE_UNIT only when the service documents a reload operation. Some daemons read PAM configuration for each authentication attempt; others need a reload or restart. A restart can interrupt users, so schedule it and confirm the unit name first. The backup file is a recovery aid, not a permanent second configuration.

5. Test a narrow match from the real client

Use a dedicated non-root account and a client whose fully qualified host name is the one in the trust file. Test the exact application that consumes SERVICE_NAME. A successful login demonstrates that the application supplied matching PAM_RUSER and PAM_RHOST values and that the files matched; it does not prove that every client is trusted safely.

Then test a deliberate negative case: use a different remote account or an unlisted client, without trying repeated guesses. The expected result is a failed authentication, normally represented by PAM_AUTH_ERR. If the local account does not exist, the module can return PAM_USER_UNKNOWN. Record the service's log message and the client identity, but do not enable verbose diagnostics on an exposed service just to make the test look clearer.

When a valid-looking request fails, check the three values separately: the local account, the remote account, and the remote host. The module cannot correct a service that leaves PAM_RUSER or PAM_RHOST unset. Check name resolution and the exact spelling in the trust file, then inspect the service's PAM and authentication logs. Do not respond by adding + or by changing the rule to trust every user.

6. Remove the trust when the test is over

For a temporary test, remove the narrow auth line and the temporary host or user entry after recording what you learned. If the module is no longer required, restore the service file from the backup only after checking that nobody else has changed it:

$ sudo diff -u /etc/pam.d/SERVICE_NAME.before-pam-rhosts /etc/pam.d/SERVICE_NAME
$ sudoedit /etc/pam.d/SERVICE_NAME
$ sudo grep -n 'pam_rhosts\.so' /etc/pam.d/SERVICE_NAME || echo 'pam_rhosts not configured'

Do not delete the backup until the service works under its intended authentication method. Removing a trust entry can lock out a user who relies on it, so coordinate the change and keep the separate administrative route until the result is confirmed.