Fix: Pseudo-terminal will not be allocated because stdin is not a terminal

In most cases, you’ll receive a confusing “pseudo-terminal will not be allocated because stdin is not a terminal” error only when you’re running some sort of SSH command from a script. If you’re running the same command from the command line, then it might work perfectly fine.

Before going any further, make sure that you’ve added your public key to the SSH agent and then try using ssh again. You might have just been missing a key. On the other hand, if this doesn’t work then you’ll need to do a little troubleshooting in your script.

Method 1: Forcing & Disabling pseudo-tty Allocation

There’s a pair of command line options that might fix the problem quickly for you. Try ssh -t -t -R followed by the rest of what you were trying to connect into in order to force pseudo-terminal allocation. For instance, let’s say you were going to use ssh -p 80 appuals@ssh.example.com to log into your account on example.com, which of course is a dummy for documentation that doesn’t exist.

Try running e.g. ssh -t -t -R -p 80 appuals@ssh.example.com and see if this fixes the problem. You’ll of course need to replace the name with your actual account and hostname in order to log successfully into the system. This forces the allocation of a terminal, so you shouldn’t see the pseudo-terminal will not be allocated because stdin is not a terminal error.

On the other hand, you might just end up with a constant string of error messages. Some users have remarked that this could be deemed amusing.

It’s certainly frustrating though regardless, so use Ctrl+C to kill the process.

You can try either using only one -t switch or increasing the number. If this doesn’t work, then replace any -t switches with a -T switch in the command, e.g. ssh -T -R -p 80 appuals@ssh.example.com and see if that works.

This method disables the entire pseudo-terminal allocation process altogether, so it might work in cases where forcing it doesn’t. Of course, none of this should be a problem from the command line, but be sure to make a note when you find which option works from your script so you can use it in any future scripts you have to run to access said server.

Since the ssh command gave these two opposite options similar names, remember that -t forces the allocation of pseudo-terminals while -T disables it. These options are case sensitive, and they’re often necessary from inside of scripts because ssh needs a traditional TTY terminal to work. Naturally, in your case you’d be using your terminal emulator for this purpose.

Method 2: Using sshpass

Some people might find that their scripts work better with the sshpass command, which isn’t included by default. You can always install it with sudo apt-get install sshpass or sudo yum install sshpass if you’d prefer to give it a try or because you need it for your specific use case.

If you’re not already using it, then you probably don’t need it. Nevertheless, you can use the same techniques to surprises error messages related to pseudo-terminal allocation in this kind of an environment as well.

For instance, use sshpass -p password ssh -T appuals@ssh.example.com to force the system to work from inside of your script.

Method 3: Fixing Job Management Errors

On occasion you might get one other error message even after fixing all of this up. If you’re receiving a warning that reads no access to tty and then you’re reminded that there’s no job control in your shell you should be able to work somewhat normally.

This error is caused by something being irregular on the remote server related to either csh, tcsh or possibly even the Almquist or other shell. You may not have noticed it because you were getting other error messages, but provided that you don’t see any others about pseudo-terminals it should be possible to continue relatively like the way you usually would.

You may not want to try using Ctrl+Z in this case to stop processes, though, because there may be no way to have them started back up again. If you’re getting an error message that reads there are stopped jobs when you exit, then you won’t be allowed to logout.

Use the ps and kill commands to close any jobs you can’t shut, assuming you don’t mind loosing work in the process. You’ll be able to exit now.