Authentication to SSH
Authentication takes two primary forms, username and password, and key-based authentication.
There is also an authenticity check performed when the client connects to the SSH daemon by confirming that the trusted public key has not changed by comparing the fingerprint that is in the trusted database
known_hosts, and what the server presents. If these match, connection continues, the server challenges for authentication, and once validated, the full session is established.
What is mutual authentication?
Before talking about SSH, let's talk about mutual authentication in a typical implementation. A TLS mutual authentication presents certificates to both the server and the client, confirming identity. This is commonly used in B2B applications, such as API endpoints. This provides the benefits of PKI (encryption in transit, integrity checking, and revocation through CRL and OCSP responders) while providing authentication of the identity.
What about implementing that in SSH?
By default, this won't work. The SSH client connects to an SSH daemon. This would require that the server have client credentials on the client. Confusing? Let's take a step back.
User (You) -> SSH key -> Server
This is normal behavior. We want to flip that and establish trust in the reverse:
Server -> Different SSH key -> User (You)
This is dangerous. There are a few reasons why:
Compromise of the server would allow pivoting to the corporate desktop network, or to a user's home network. Either situation would be devastating.
ACLs in the enterprise should not allow this to happen. This makes pivoting and data exfiltration much simpler for an attacker.
This is possible, but rarely done, and is dangerous.