Failure Scenario

Linux SSH works by IP but fails by short name after resolver configuration changes.

This guide is for the common contradiction where the server is reachable and SSH itself is fine, yet hostname-based access fails because the local resolution path changed in ways the team did not account for.

Search Linux AccessOpen Linux Domain
Situation

Transport success can hide a pure name-resolution failure.

If SSH works by IP, the connection path and service availability are probably fine. The question becomes which resolver path the host or admin workstation uses for the name, and whether that path changed with search domains, local resolver behavior, or host overrides.

What To Verify

Prove whether this is a name problem or an access problem.

  • Test short name versus FQDN explicitly and compare responses.
  • Check `getent hosts`, `resolvectl`, and `/etc/hosts` on the client system.
  • Confirm whether the failing name relies on a search domain that no longer applies.
  • Review host key handling separately so name and trust issues are not mixed together.
  • Identify whether the application path uses NSS the same way the shell does.
Working Sequence

Reduce the problem to a predictable lookup path.

  • Validate access by IP to confirm service and network availability.
  • Use FQDN and short name tests side by side.
  • Inspect search domain and routing domain behavior on the initiating host.
  • Remove stale `/etc/hosts` assumptions or local overrides if present.
  • Standardize on FQDNs until the short-name model is proven again.