Who actually sees your SSH password on an untrusted VPN?

Route an SSH session over a VPN you do not operate and the password still belongs to the SSH server, not to the network in between. If the transport to a verified host is properly protected, a passive observer on that path does not get the password in readable form. Change one condition, though, and the answer changes: an unverified host, a weakened cipher list, or a compromised workstation all produce different outcomes. Run the checks below in order, and treat each one as a stop condition.

Name the recipient before you type anything

The password field travels inside an authentication message, and that message travels inside the encrypted transport. Confidentiality is a property of the transport, which means it depends on having negotiated protection and on having negotiated it with the host you intended. That second half is the part people skip. A connection encrypted to an impostor is confidential and useless at the same time. The VPN login proves nothing about the SSH host, and the provider's reputation is not a substitute for the key check.

Keep the two directions separate in your head. The host key answers which server you reached. Password or key authentication answers which user the server accepts. Improving the second never repairs the first.

Check the host identity, the record and the negotiation

Start on the client with the record you already hold. A published fingerprint compared against a trusted source, and a known_hosts entry that still matches, give you the only evidence that matters before authentication begins.

ssh-keygen -F ssh.internal.example.net -f ~/.ssh/known_hosts
ssh -o StrictHostKeyChecking=yes ssh.internal.example.net

On the server side, print the fingerprints you intend to publish instead of copying them from memory. Distributing those out of band is the whole point; a fingerprint pasted from the same chat channel as the hostname proves only that both came from the same place.

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub
sudo sshd -T | grep -E 'hostkey|kexalgorithms|cipher'

The negotiated algorithms come from the intersection of both sides. If a client configuration pins an obsolete key exchange to reach an old device, that choice applies to every host it talks to, so scope it to that host rather than globally.

Read the methods the server actually accepts

Knowing which authentication methods a server permits tells you what the password is even for. A host that accepts only public keys has no password exchange to protect, and a host that still accepts passwords deserves a deliberate decision rather than an inherited default.

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication|permitrootlogin'

Switching a user to key authentication removes that user's password from that exchange. It does not make a compromised workstation safe, and it does not make an untrusted remote session harmless. Those are different risks with different controls. Also decide about agent forwarding. Forwarding an agent into an untrusted host hands that host the ability to use your keys while the session lasts, which is a larger exposure than the password question that started this.

Handle a host-key warning as an incident step

When the client warns that the host identification changed, stop and verify through a channel that does not pass through the same network path. Compare the fingerprint with the server console or with the operator who rebuilt it. Deleting the old entry to silence the warning is the one action to refuse. It discards the evidence and converts a possible interception into a normal login.

If the host was legitimately rebuilt, remove the stale entry only after the new fingerprint is confirmed, then reconnect and re-check the negotiation. Record the change with the date and the reason, because the next person will see the same warning and needs to know it was resolved.

What this runbook does not cover

A VPN operator watching traffic is not the same as software with local privileges on your machine. Endpoint compromise, a hostile browser extension or a keyboard logger sits below anything SSH can negotiate, and no tunnel changes that. If the workstation is suspect, follow the incident process rather than testing secrecy by reconnecting through a different exit. Reconnecting proves the network path changed and nothing about the endpoint.

Finish with the ordinary case: verified host, protected transport, the authentication method you chose on purpose, and no forwarding you did not need. That combination is the answer to the question in the title, and it is four decisions rather than one.