Introduction

A privileged access migration can introduce the new SSH bastion while administrator sessions still transit the old one. Engineers connect successfully but from the wrong jump host, audit trails stay on the retired platform, or one workstation uses the new path while another still traverses the previous bastion because ProxyJump, included SSH config files, and access wrapper scripts often outlive the infrastructure move.

Treat this as an SSH routing problem instead of a generic login issue. Start by checking which jump host an affected SSH session actually uses in the live connection path, because migrations often validate the new bastion manually while daily admin workflows continue following older ssh_config aliases or wrapper tooling.

Symptoms

  • SSH sessions still transit the old bastion after migration
  • Audit logs or session recording still show activity on the retired jump host
  • One admin workstation uses the new bastion while another still uses the previous path
  • SSH access fails only after the old bastion is disabled
  • Direct login to the target host may work, but normal admin workflow still uses the old jump path
  • The issue started after moving bastions, PAM tooling, or administrative access infrastructure

Common Causes

  • ~/.ssh/config or included config fragments still specify the old ProxyJump or ProxyCommand
  • Wrapper scripts, terminal profiles, or access tooling still inject the previous bastion host
  • DNS aliases or host aliases still resolve the bastion name to the old server
  • One admin image or shell profile was updated while another still ships the retired SSH path
  • Centralized access tooling was migrated, but local workstation config was not
  • Validation confirmed the new bastion accepted SSH traffic but did not verify what path administrators actually used in routine sessions

Step-by-Step Fix

  1. Capture one affected SSH session with verbose connection output and record the actual jump host or proxy command it uses, because the runtime connection chain determines what bastion handles the session.
  2. Compare that active SSH path with the intended post-migration design, because one stale config include or wrapper script can keep many admins tied to the retired bastion.
  3. Review ssh_config, included fragments, shell aliases, wrapper scripts, access tooling, and DNS aliases for references to the old bastion, because SSH routing often spans local user config and central admin tooling.
  4. Check different admin workstations, shells, and automation jobs separately if behavior differs, because migrations often fix one launch path while another still injects the previous jump host.
  5. Update the authoritative SSH routing configuration so affected sessions transit the intended bastion, because deploying the replacement jump server alone does not retarget existing client-side connection logic.
  6. Launch a controlled SSH session and confirm the intended bastion handles the connection and logging path, because a successful shell prompt does not prove the right jump host was used.
  7. Verify the old bastion no longer receives SSH transit traffic from migrated admins or automation, because split privileged-access paths can remain hidden while both hosts stay reachable.
  8. Review host keys, MFA hooks, and agent-forwarding policy if sessions still fail after retargeting, because the destination can be correct while trust or auth integration still breaks access.
  9. Document which team owns admin workstation config, access tooling, and migration validation so future bastion moves verify the actual SSH path used by operators before retiring the previous environment.