Understanding the Security Model
The confusion often stems from mixing up SSH connection persistence with authentication requirements. When you connect via SSH, you establish a control socket. If you open a new terminal window and typessh user@host, you are initiating a completely new authentication handshake. Google Authenticator (PAM) is designed to challenge every distinct authentication attempt to verify your identity at that specific moment. This is critical for security because it mitigates the risk of stolen sessions being reused by malicious actors who might have intercepted the connection.
It is important to note that once authenticated, subsequent commands within that same shell session do not trigger additional prompts. The re-authentication only occurs when you initiate a new connection or use tools that explicitly request credential renewal. This behavior is consistent across Linux distributions running on EC2, whether you are using Ubuntu, Amazon Linux, or CentOS. For more details on setting up the initial user environment, see Configuring a New User on AWS EC2 with SSH (Ubuntu).
Distinguishing Between Connection Types
Many users believe they need to disable the prompt entirely, but the real issue is usually how they manage their SSH connections. If you are experiencing repeated prompts, it is likely because you are opening multiple separate SSH sessions rather than keeping one alive. To maintain a single session, you should use SSH multiplexing. This allows you to open multiple terminal windows that share the same underlying network connection. When you configure multiplexing, the first connection performs the full authentication, including the Google Authenticator step. Subsequent connections reuse this authenticated channel, meaning no new PAM challenges occur. This approach maintains high security while improving usability. You achieve this by modifying your local SSH client configuration file, typically located at~/.ssh/config on your local machine.
Configuring SSH Multiplexing
To implement this solution, add the following lines to your~/.ssh/config file:
Host *
ControlMaster auto
ControlPath /tmp/%r@%h-%p
ControlPersist 600Host *). The ControlPath directive specifies where the socket file is stored, ensuring uniqueness per user, host, and port. The ControlPersist 600 setting keeps the master connection alive for 600 seconds (10 minutes) after the last client disconnects. This means if you close your terminal but return within ten minutes, your next connection will be instant and silent, bypassing the need for another Google Authenticator code.
If you need to force a new authentication for security reasons, you can kill the master process manually. This forces the next connection to go through the full PAM flow, including the TOTP check. This gives you granular control over when re-authentication occurs without changing server-side PAM settings.
Why Server-Side Changes Are Not Recommended
Some guides suggest modifying/etc/pam.d/sshd to remove the Google Authenticator module for certain conditions. This is dangerous and unnecessary. Disabling the module weakens your EC2 instance's security posture significantly. Since you are using MFA, you have already added a strong layer of protection. Removing the second factor for "existing" sessions creates a false sense of security; if an attacker compromises your account credentials, they could potentially bypass MFA if the logic is flawed.
Furthermore, PAM modules like Google Authenticator are stateless regarding individual sessions. They do not track whether a session is "new" or "old" in the way application-level software might. They only respond to the authentication request generated by the SSH daemon. Therefore, trying to trick the PAM stack into skipping checks is technically complex and prone to failure. Instead, rely on the SSH client side to manage connection reuse.
For users concerned about password authentication fallbacks, it is worth noting that disabling passwords entirely is a best practice when using key-based auth and MFA. See Possible Disable Password Authentication with Google Authenticator in Linux SSH Logins? for guidance on hardening your authentication methods.
Troubleshooting Persistent Connections
If you find that new connections still prompt for Google Authenticator despite having multiplexing enabled, check your SSH verbose output. Runssh -v user@host to see the negotiation details. Look for lines indicating Connection to host closed. or errors related to the control socket. Common issues include incorrect permissions on the /tmp directory or firewall rules blocking the loopback interface used for internal communication between the master and slave processes.
Ensure that your local SSH client version supports multiplexing, which is standard in OpenSSH 4.0 and later. Most modern Linux distributions and macOS come with compatible versions. If you are connecting from Windows, ensure you are using a recent version of OpenSSH included in Windows 10 and 11, or a third-party client like PuTTY that supports similar connection sharing features.
Another potential issue is the ControlPersist timeout. If you wait longer than the specified time before reconnecting, the master process may have exited, causing the next connection to be treated as fresh. Adjust the ControlPersist value based on your workflow. A higher value reduces prompts but consumes slightly more system resources on the client side to keep the socket open.
Alternative Approaches for Automation
In some automated scenarios, such as CI/CD pipelines, interactive MFA is impossible. In these cases, you should not use Google Authenticator for SSH directly. Instead, use short-lived IAM roles or AWS Systems Manager Session Manager. These tools provide secure access without requiring manual TOTP entry. For legacy systems where SSH is mandatory, consider using certificate-based authentication combined with hardware keys, which can be configured to cache credentials more effectively than software TOTP. Always test your changes in a non-production EC2 instance first. Verify that you can reconnect seamlessly and that security logs in CloudWatch reflect the expected authentication events. Properly configured multiplexing provides the best balance between security and convenience for daily development workflows.Frequently Asked Questions
Can I disable Google Authenticator for trusted IPs?
Yes, you can configure PAM to skip challenges for specific source IP addresses. However, this is risky if your EC2 instance is accessible from the public internet, as IP spoofing is possible. It is generally safer to rely on SSH multiplexing for user convenience instead.
Why does my SSH session drop and ask for MFA again immediately?
This usually happens if the network connection times out or if the SSH control socket is deleted. Check your ServerAliveInterval setting in your local SSH config to keep the connection active. Also, ensure no other process is interfering with the temporary socket files in /tmp.
Does Google Authenticator work with AWS Systems Manager?
No, Systems Manager Session Manager does not support Google Authenticator directly. It uses IAM policies and SSM agent configurations for authentication. If you need MFA, apply it at the IAM level using AWS Identity and Access Management Console settings.
How do I manually clear cached SSH connections?
You can remove the control socket file associated with the host. Find the socket in the path defined by ControlPath (often in /tmp) and delete it. Alternatively, run ssh -O exit user@host to gracefully terminate the master connection.
Is it safe to use ControlPersist indefinitely?
Setting ControlPersist to a very long duration or yes keeps the connection open until manually closed. While convenient, this increases the window of opportunity for session hijacking if your local machine is compromised. Use moderate timeouts like 600 seconds for a better security balance.