Kerberos clearly keeps an attacker from getting a user's credentials in an SSH man-in-the-middle scenario (one where the attacker has gotten the user to trust their server's public key and redirects traffic through that server). However, what if an attacker is okay with not getting the user's credentials because they'll be able to listen to the session after authentication and potentially get valuable information, including subsequently entered credentials.
To be clear, here is the scenario:
- SSH server (Server1) and client (User1) are set up for Kerberos. Server1 has standard public/private key pair for authentication, etc.
- User1 initially attempts to connect to Server1 but their connection is redirected by an attacker to Server2.
- User1 doesn't look closely at the public key from Server2 that is presented and accepts it as a known host key for Server1 (thus setting up the MITM).
- User1 goes through Kerberos authentication with Server1 through Server2 (Server2 sets up two separate SSH sessions and passes information between them). Attacker doesn't gain any valuable information during authentication because of the way Kerberos works.
- Once authenticated, however, User1 starts performing operations on Server1, including sudo. Attacker is able to see all of the contents of the session as they pass through Server2.
Would this work? This scenario would obviously be thwarted using public key authentication during the authentication step. But is there something in the Kerberos or SSH protocol that would prevent this situation?
service ticket
concept in Kerberos which is designed to prevent man in the middle attacks.