MITM and trust

SSH authenticates the server by its host key, trusted on first use and pinned in known_hosts, or signed by a CA for certificate-based SSH. Where that trust is weak, users who ignore host-key warnings, clients set to accept any key, or certificate validation flaws, a positioned attacker performs a machine-in-the-middle to capture credentials and hijack the session.

1 phút đọccập nhật 7 thg 10, 2026florianamette1 người đóng góp
Hỏi trợ lý của bạn (MCP)Sửa trên GitHub

SSH resists machine-in-the-middle attacks because the client verifies the server's host key: on first connection the key may be recorded in known_hosts (trust on first use), and later connections must match. Certificate-based SSH replaces per-host pinning with trust in a CA that signs host keys. The attack surface is where that trust is weak: a client configured to accept unknown or changed keys, a first connection whose fingerprint is not verified out of band, a poisoned known_hosts, or compromise of a trusted host CA. A positioned attacker can then interpose, present a substitute host key, capture password authentication, and observe or alter the plaintext session. Public-key authentication does not transmit the private key; onward use of that identity requires another capability, such as access to an explicitly forwarded agent.

bash
# position (ARP/DNS/route) + an SSH MITM proxy that presents a substitute host key
# the attack succeeds when the client does not reject the unknown/changed key

Subtopics#

References#