SSH authentication becomes weaker when it relies only on app generated one time codes because the same secret may be reused across systems, the code can be relayed by a phisher, and the user has little signal about which application is asking for approval. That combination increases the chance of unauthorized access despite apparent two factor coverage.
Why app-generated one time codes are weaker than they look in SSH
App-generated one time codes are usually treated as a second factor, but in SSH they often act more like a shared secret with a short expiry than a true phishing-resistant check. The important weakness is not the time window alone, it is that the code can be copied, replayed, or accepted without the user having a strong device-bound signal about the login request.
That means the protection is only as strong as the path between the user and the server challenge. If the code can be intercepted in real time, or if the same secret underpins multiple authentications, an attacker may still satisfy the login flow even though a code was entered correctly.
For a deeper look at why code-based approvals are less robust than phishing-resistant methods, see NIST SP 800-63 Digital Identity Guidelines and Passwordless and Passkeys Guide.
What breaks in the SSH threat model
Three things break at once. First, the code is not strongly bound to the SSH session, so a phisher or relay attacker can capture and forward it in near real time. Second, app-generated codes often rely on a seed or shared secret that is not unique to the specific login event, so compromise of the secret can undermine multiple approvals. Third, the user sees a code prompt, not a clear, trustworthy description of the application, host, or action being approved.
That lack of context is what makes social engineering effective. If the person approving the login cannot tell whether the prompt belongs to the expected SSH session, they may approve an attacker-controlled prompt that looks routine. SSH then inherits the same weaknesses seen in other OTP relay and MFA-bypass attacks, even though the transport and protocol are different.
These failure modes are illustrated in Twilio 0ktapus breach 2022, CitrixBleed exploitation 2023, and Uber Breach.
SSH also has a stronger consequence profile than many consumer logins because one successful sign-in can open access to administration, automation, secrets, and lateral movement paths. When the authentication control is weaker than the environment it protects, the practical result is not just account risk, it is host-level trust failure.
For that reason, SSH should be treated as a high-value access path, not just another MFA-enabled login. The relevant control question is whether the second factor is actually resistant to relay, phishing, and secret reuse under real attacker pressure.
What a safer SSH login design should preserve
Safer SSH authentication preserves two properties: the secret must not be reusable in a way that helps an attacker, and the user must have an unambiguous signal about what is being approved. If either property is missing, the control may still slow down opportunistic abuse, but it will not reliably stop a targeted attacker.
In practice, that pushes teams toward phishing-resistant authenticators, device-bound methods, or challenge flows that are harder to relay than a generic one time code. It also means treating recovery, fallback, and help-desk bypass paths as part of the authentication design, because attackers often target the weakest alternate path rather than the primary one.
Useful references for the stronger design pattern are Workforce Identity Security Guide, Passwordless and Passkeys Guide, and RFC 8705: OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens.
Risk and Threat Considerations
App-generated one time codes create a false sense of strong authentication when the real weakness is relayability. In SSH, that is especially dangerous because an attacker who obtains a valid code during the window can convert a single social engineering success into administrative access.
Failure mechanism: The code is copied or relayed in real time, or the shared seed is abused, so the login succeeds even though the user never intended to authorize the SSH session.
Impact: The attacker can reach privileged hosts, steal secrets, pivot through infrastructure, and use the SSH foothold for persistence or lateral movement.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Digital Identity Guidelines | Sets assurance expectations for phishing-resistant authentication and authenticator strength. |
| Recommendation — Use phishing-resistant authenticators instead of relayable OTP-only approvals for SSH. | ||
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | SSH login for employees is a user authentication control problem. |
| IA-5 — Authenticator Management | One time codes depend on authenticator lifecycle and secret handling. | |
| AC-6 — Least Privilege | SSH compromise becomes more damaging when access is overbroad. | |
| Recommendation — Require stronger user authentication for SSH access to privileged systems. Manage authenticator secrets to prevent reuse, leakage, and weak fallback paths. Limit SSH privileges so a stolen code cannot expose unnecessary host access. | ||
| OWASP ASVS | V6 — Authentication | Authentication strength and phishing resistance are central to the question. |
| Recommendation — Verify that the authentication method is resistant to relay and prompt abuse. | ||
Practitioner Guidance
What to verify: Confirm whether the SSH factor is actually phishing-resistant and whether the user receives a session-specific approval signal that names the host, action, or origin. If the login prompt does not meaningfully identify the request, treat the control as weaker than its label suggests.
Decision rule: If the second factor can be relayed or reused, prioritise replacing it before expanding SSH access. If the environment includes administrative shells, automation endpoints, or privileged jump hosts, the tolerance for generic OTP-style approval should be very low.
Practitioner takeaway: The key question is not whether SSH has a second factor, but whether that factor resists relay and gives the user enough context to recognise a malicious approval request.
Related resources from NHI Mgmt Group
- Why do usernames, passwords, and one-time codes create weak assurance in modern authentication flows?
- What breaks when multi-factor authentication still relies on SMS codes or push approvals?
- How should security teams evaluate passwordless authentication approaches that still depend on passwords or one-time codes?
- When does biometric authentication become a better control than passwords or one-time codes for customer transactions?
