Fix SSH Enter Passphrase When stdin Is Not a Terminal (2026)

It turns out the SSH client, when trying to connect to a remote host and needing a passphrase for your private key, got confused because it couldn’t ask you for the password interactively.

Common Causes and Fixes

1. ssh-agent Not Running or Not Loaded:

   • Diagnosis: Run ssh-add -l. If you see "The agent has no identities" or "Could not open a connection to your authentication agent," the agent isn’t running or accessible.
   • Fix: Start ssh-agent and add your key.

     eval "$(ssh-agent -s)"
     ssh-add ~/.ssh/id_rsa
     

     The eval command sets the necessary environment variables (SSH_AUTH_SOCK and SSH_AGENT_PID) so ssh and ssh-add know where to find the agent. ssh-add then registers your private key with the running agent, so ssh can request the passphrase from the agent instead of directly from the terminal.
   • Why it works: ssh-agent is a background process that holds your decrypted private keys in memory. When ssh needs to authenticate, it asks the agent, which then provides the necessary credentials without ever prompting your terminal.

2. Running ssh within a Non-Interactive Script/Shell:

   • Diagnosis: You’re executing an ssh command from a script (e.g., a cron job, a CI/CD pipeline script, a shell script run with bash -c "...") and it fails with this error.
   • Fix: Use ssh-agent as described above, or configure your SSH client to use a key that doesn’t require a passphrase (not recommended for security), or use a configuration file to specify the key and bypass the passphrase prompt if the agent is available.

     # In ~/.ssh/config
     Host your_remote_host
         IdentityFile ~/.ssh/id_rsa_nopass
         # Or if using agent, ensure agent forwarding is enabled if needed
         # ForwardAgent yes
     

     If you must use a passphrase-protected key in a script, ssh-agent is the standard way. The IdentityFile directive tells ssh which private key to use. If this key is managed by ssh-agent, ssh will query the agent.
   • Why it works: Scripts don’t have a user at a terminal to prompt for a passphrase. By using ssh-agent or a key without a passphrase, you provide the authentication mechanism without requiring interactive input.

3. SSH Connection Forwarding Issues (Agent Forwarding):

   • Diagnosis: You’re SSH’d into a server (ServerA) and from ServerA you’re trying to SSH into another server (ServerB), and you get this error when ServerB requires your SSH key’s passphrase.
   • Fix: Ensure agent forwarding is enabled on the initial SSH connection from your local machine to ServerA.

     ssh -A user@ServerA
     

     Then, on ServerA, ensure ssh-agent is running and your key is added (ssh-add).
   • Why it works: Agent forwarding (-A) allows your local ssh-agent to authenticate connections made from ServerA to ServerB. When you connect from ServerA to ServerB, ServerA’s SSH client forwards the authentication request back to your local ssh-agent (via the SSH_AUTH_SOCK socket established by the -A flag), which then uses your local decrypted private key.

4. ssh Command Invoked with </dev/null:

   • Diagnosis: You’re running ssh and explicitly redirecting standard input from /dev/null.

     ssh user@host < /dev/null
     

   • Fix: Remove the input redirection, or use ssh-agent.

     ssh user@host
     

   • Why it works: Redirecting standard input from /dev/null explicitly tells ssh that there will be no input available, including no way to prompt for a passphrase. This forces the "stdin is not a terminal" error.

5. Using sshpass Incorrectly or sshpass Not Installed:

   • Diagnosis: You’re trying to use sshpass to provide the passphrase non-interactively but it’s not working or not installed.
   • Fix: Install sshpass (e.g., sudo apt-get install sshpass or brew install sshpass) and use it correctly. Warning: Storing passphrases in plain text is a significant security risk.

     sshpass -p 'your_passphrase' ssh user@host
     

     Or, more securely, read from a file:

     sshpass -f /path/to/passphrase_file ssh user@host
     

   • Why it works: sshpass is a utility designed to provide a password to commands that prompt for it. It intercepts the prompt and supplies the password from its arguments or a file. However, it’s generally less secure than ssh-agent for managing private key passphrases.

6. Incorrect SSH_AUTH_SOCK Environment Variable:

   • Diagnosis: You’ve manually set or inherited an incorrect SSH_AUTH_SOCK environment variable, pointing to a non-existent or invalid socket file. Run echo $SSH_AUTH_SOCK.
   • Fix: Unset the variable or restart your shell/login session to get the correct value from ssh-agent.

     unset SSH_AUTH_SOCK
     eval "$(ssh-agent -s)" # Restart agent and set correctly
     ssh-add ~/.ssh/id_rsa
     

   • Why it works: The SSH_AUTH_SOCK variable is the communication channel between ssh and ssh-agent. If it’s pointing to the wrong place, ssh can’t find the agent to get the key information, leading it to try and prompt your terminal, which fails.

The next error you’ll likely encounter after fixing this is a "Permission denied (publickey)" error, indicating that the SSH server rejected your authentication attempt, possibly because the correct key wasn’t presented or authorized on the server.