Two SSH Aliases, One Server: Direct VPN or Jump Host

Keep an approved VPN path and an approved bastion path as separate aliases and bookmarks, so no shortcut has to guess which route is authorized.

The same private server answers over an approved VPN and through an approved bastion, and you want one Emacs bookmark for each rather than a shortcut that guesses. The decision is not which path is better; it is which path is authorized for the work in front of you. Keep both explicit, name them separately, and let the file name say which one you chose.

Condition one: which paths are approved?

A jump host is not an automatic fallback around a VPN requirement, and a VPN is not a licence to skip an approved bastion. Ask which routes are authorized for your account and for this data. If both are, you have a choice; if only one is, the bookmark set has one entry. That answer comes from the data owner, not from whichever route happens to work today.

Write the answer down, because the distinction disappears in a hurry during an incident.

Both paths also need their own account and identity configuration. A shared alias that works over one route can fail over the other for reasons that have nothing to do with the network.

Condition two: can you name each path distinctly?

An SSH config can hold two host aliases for one address, each with different proxy behaviour. Put the specific blocks before any broad wildcard, because the first value obtained wins for most options.

Host proj-direct proj-bastion
    HostName 10.60.0.21
    User analyst
    ControlPath none

Host proj-direct
    ProxyJump none

Host proj-bastion
    ProxyJump gw.example.com

The address above is an example; substitute the one your team documents. The jump alias needs the bastion's approved account too, which usually means a second Host block for the bastion itself. Disabling connection sharing here keeps a path comparison honest, since a reused multiplexed connection can outlive the route change you are trying to observe.

Then the remote file names stay distinct and readable.

/ssh:proj-direct:/srv/project/README.md
/ssh:proj-bastion:/srv/project/README.md

Condition three: does the editor know the difference?

TRAMP treats those two file names as different destinations, which is what you want. Bookmark each under a name that says which path it uses, and reopen the bookmark instead of editing a single destination's meaning. Two bookmarks also make the comparison visible: you can open both and see which one fails without changing any configuration.

One setting deserves attention when ProxyJump is involved: TRAMP's connection sharing has to be off for the relevant connections, so set tramp-use-connection-share to nil before you open them. That is a compatibility setting, not a fix for a missing route, and it does not make an unauthorized path authorized. The TRAMP FAQ documents bookmarks as the supported way to shorten these names.

A bookmark that silently changes route is worse than no bookmark at all.

Why the network icon proves nothing

NetworkManager's overall state value 70 means the machine has global connectivity. It does not name a VPN profile, and ordinary Wi-Fi satisfies it. A private-only tunnel that carries exactly the route you need may leave that aggregate value untouched. That is why a shortcut keyed to the icon can report readiness for a path it has never tested.

Read the specific connection's state instead of the global one.

If you automate anything, query the named connection, then check the target route, the resolver answer and SSH reachability in that order. Each of those can fail while the previous one succeeds, and collapsing them into a single boolean is how automation ends up reporting success for a path it never used.

What to do when a path stops working

Save your buffers before investigating, because an existing TRAMP session can outlive a route change and then fail at the next write. Close it through the supported cleanup, reopen the bookmark, and compare the two paths rather than assuming the server is down.

Keep host-key verification on for both the bastion and the destination.

A different route does not entitle you to accept a server key you did not expect, and it does not make an unapproved path acceptable either. Both are separate decisions from the one you were making.

ተዛማጅ ጽሑፎች